Support for OAuth2 endpoint discovery about oslo HOT 7 CLOSED

By magically, I mean like requiring PKCE for providers that support it etc.

from oslo.

We could probably add an API that parses the well known config, but I'm not sure how it could automatically configure PKCE since that's defined within createAuthorizationURL() instead of the entire OAuth2Client class

from oslo.

Yes, that's true. What was the reason to export a separate function createAuthorizationURL instead of exposing it as a class method?

from oslo.

It is a class method?

from oslo.

Yeaaaah, sorry about that. I shouldn't post from my phone late in the evening. 😆 Was thinking of something else.

We could focus on automatically discovering and configuring the /token and /authorize endpoints via the .well-known discovery endpoint IF a user instantiates the client without token and authorize endpoints BUT provides the discovery endpoint. This is how it works in the oauth2-client lib. The createAuthorizationURL method would still expect its arguments as-is for PKCE. The benefit would be that the client would continue to function just fine if the oAuth2 server decided - for whatever reason - to change the urls of either token or authorize endpoint.

Let me know if I'm still missing your point. ;-) Very well possible.

from oslo.

Sorry, got Oslo and Arctic providers mixed up.

Honestly though, If you know the well known endpoint, I feel it's easier if you just copy paste the authorization and token endpoint. It would be nice if Oslo could parse the well known config and magically update the types to require certain items, but I don't think that would be realistic.

from oslo.

What do you mean by magically updating the types? If you are talking about the client instantiation, this could simply be handled by a union type if the arguments were all passed in a single object:

new OAuth2Client({
    clientId,
    authorizeEndpoint
    tokenEndpoint,
    redirectURI
});

OR

new OAuth2Client({
    clientId,
    discoveryEndpoint,
    redirectURI
});

The Options type would look something like this:

type OAuth2ClientOptions = {
    clientId: string,
    authorizeEndpoint: string,
    tokenEndpoint: string,
    redirectURI: string
} | {
    clientId: string,
    discoveryEndpoint: string,
    redirectURI: string
}

It would force the user to either be explicit with the endpoints or let the client handle it via parsing the well-known config.

Having said that, I recognize that the additional fetching logic and parsing of the well-known config adds quite a bit of complexity. The benefit as said earlier is that it allows OAuth Providers to change the endpoints without breaking clients downstream. If you decide that that is not worth the added complexity I'm absolutely fine with that! This library is fantastic already as-is so thanks again for it!

from oslo.