💡 [REQUEST] - Support discovery endpoint

[bratanon]

Summary

Instead of having to specify all endpoints explicitly, some oauth providers have server metadata or OpenID Connect Discovery endpoints.

Basic Example

  const authConfig = {
    clientId: config!.client_id,
    scope: 'toolsAdmin',
   ....
   discoveryEndpoint:  'https://accounts.google.com/.well-known/openid-configuration'
  } satisfies TAuthConfig;

Which resolves in

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
 "token_endpoint": "https://oauth2.googleapis.com/token",
 "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
 "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 "response_types_supported": [
  "code",
  "token",
  "id_token",
  "code token",
  "code id_token",
  "token id_token",
  "code token id_token",
  "none"
 ],
 "subject_types_supported": [
  "public"
 ],
 "id_token_signing_alg_values_supported": [
  "RS256"
 ],
 "scopes_supported": [
  "openid",
  "email",
  "profile"
 ],
 "token_endpoint_auth_methods_supported": [
  "client_secret_post",
  "client_secret_basic"
 ],
 "claims_supported": [
  "aud",
  "email",
  "email_verified",
  "exp",
  "family_name",
  "given_name",
  "iat",
  "iss",
  "name",
  "picture",
  "sub"
 ],
 "code_challenge_methods_supported": [
  "plain",
  "S256"
 ],
 "grant_types_supported": [
  "authorization_code",
  "refresh_token",
  "urn:ietf:params:oauth:grant-type:device_code",
  "urn:ietf:params:oauth:grant-type:jwt-bearer"
 ]
}

Drawbacks

More code to maintain.

Unresolved questions

No response

Implementation PR

No response

Reference Issues

No response

[sebastianvitterso]

Hey @bratanon! Thanks for your interest in the project!

The main take-away for a feature like this is simplified user experience, as they won't have to input the two token urls, but only the discovery url, right?

Initially I'm a bit sceptical of this idea, not because it wouldn't work or it wouldn't potentially make it easier for users, but for two specific reasons:

1. It would add a bit more complexity to the code without offering much on the other end. Users would have to enter either a discovery endpoint url, or the two token endpoints. Wouldn't make sense to have a mix of these cases, so we'd have to add some validation for that.
2. Using the discovery url instead of the token url directly would require the library to make one more API-call for every page-refresh, so that it could retrieve the token urls. One option here would be to cache them, but that would certainly add to the complexity, as we would then have to implement some cache-invalidation logic, which isn't always the easiest to get working smoothly.

Additionally, given the discovery endpoint url, it should be trivial for the developer to just retrieve the two token endpoints at develop-time, and just input those, right?

I'm certainly open for a discussion here, and also for changing my mind, given reason 😄

Could you elaborate on the pro's of such a solution, @bratanon?

Cheers!

[bratanon]

I appreciate your thoughtful response to the idea of using a discovery URL. I totally understand your concerns, but I really believe that this approach can significantly enhance the user experience. Here are some points to consider:

• Simplified Configuration:

  • Users only need to provide a single discovery URL, which reduces the chances of errors when entering multiple endpoint URLs.
  • This makes the setup process much more straightforward, especially for those who may not be as familiar with OAuth configurations.

• Automatic Updates:

  • By relying on the well-known contract, any changes to the OAuth provider's endpoints will be automatically reflected without requiring users to update their configurations manually.
  • This can save time and reduce maintenance overhead for developers.

• Reduced Complexity for Users:

  • New users or developers won't need to understand the intricacies of OAuth endpoints. They can simply use the discovery URL and let the library handle the rest.

• Potential for Caching:

  • While there is an additional API call, implementing caching strategies can mitigate performance concerns. Cached endpoints can be reused until invalidated, minimizing repeated calls.
  • This caching can be designed to be efficient and smooth, ensuring that the user experience remains responsive.

• Encouraging Best Practices:

  • Using discovery endpoints encourages developers to follow best practices in OAuth implementations, promoting a more standardized approach across different applications.

I hope these points help clarify the benefits of adopting this discovery URL approach! I'm looking forward to hearing your thoughts on this.

Cheers!

[soofstad]

Hi @bratanon
Just wanted to test how this feature would fit into the code base.
It's not too bad, if we think that calling logIn() or logOut() is a satisfying cache invalidation strategy.

Please test out the PR #207