OpenID Connect support?

[empz]

It's not clear to me if this library supports OpenID Connect providers. Specifically, I'd want to use it against an IdentityServer4.

Is it supported? If not, are there any plans to support it?

[iaincollins]

That's a good question!

We don't explicitly have built-in OpenID Connect support currently, but we do have built-in support OAuth providers that support OpenID Connect, such as Google and Apple, Auth0 and others.

The practical answer is that it right now there is a good chance v2 will work with an OpenID Connect service (with the right configuration options) but we don't currently explicitly support the standard itself, just the underlying OAuth 2 spec (which is much looser).

I'm very happy to receive code contributions that would help improve support for OpenID Connect and I am happy to take bug reports and feature requests to try to resolve issues with specific clients, where particular defects or specific missing features can be identified.

Full compliance with OpenID spec is probably unlikely to happen with out some form of paid sponsorship, as the specification is quite detailed and would take not insignificant about of work, but I'm happy to take a best effort basis.

To that end it is helpful for people are able to share provider configurations they have to allow us to bundle them as built-in providers if they are likely useful to other people.

I'm happy to help with specific integrations; there are still some as-yet undocumented features and tips I can share and I plan on making it easier to debug problems with better error / response logging for OAuth flows when in debug mode.

[geraldnolan]

@eparizzi Yes, this library will work with IdentityServer4. I have already confirmed it. You will need to add a custom provider. https://next-auth.js.org/options/providers

{
      id: 'IdentityServer4',
      name: 'IdentityServer4',
      type: 'oauth',
      version: '2.0',
      scope: 'profile openid email offline_access',
      params: { grant_type: 'authorization_code' },
      accessTokenUrl: process.env.IdentityServer4_URL + '/connect/token',
      requestTokenUrl: process.env.IdentityServer4_URL + '/connect/token',
      authorizationUrl: process.env.IdentityServer4_URL + '/connect/authorize?response_type=code',
      profileUrl: process.env.IdentityServer4_URL + '/connect/userinfo',
      profile: (profile) => {
        return {
          id: profile.sub,
          name: profile.name,
          email: profile.email,
        }
      },
      clientId: process.env.IdentityServer4_ID,
      clientSecret: process.env.IdentityServer4_SECRET
    },

@iaincollins I was thinking of making an IdentityServer4 provider Doc similar to the code above? It maybe useful to have a clientBaseUrl. This provider has a Discovery Url that allows you figure out the endpoints for each section.

Here is an example: https://demo.identityserver.io/.well-known/openid-configuration

[iaincollins]

Thanks @geraldnolan!

That would be great - and that approach makes sense!

It seems we actually have a couple of providers that have a similar extra property to specify a domain or subdomain.

• https://next-auth.js.org/providers/auth0
• https://next-auth.js.org/providers/okta

BTW (somewhat related) I only discovered this weekend work you did to support the Apple JWT token is actually something part of the OpenID spec - I think they call them ID Tokens? - I couldn't think of a great name for it but I've added it as an option so it can be used on other providers: https://next-auth.js.org/configuration/providers#using-a-custom-provider

[empz]

Thank you for the example, I got a first version working.

Reading the docs, it seems there's no way to get the access token in the browser, correct? All the calls to the API protected by the IdentityServer are supposed to be done from the server (inside an API route). Is that correct?
My app is not publicly exposed and since it's everything behind authentication, server-side won't be that helpful. I'd want to avoid the extra request to the API routes and just hit the API I need directly from the client.

Is there a way to return the access_token to the browser?

[empz]

Actually I can't even get the access token inside an API route.

The example shown here doesn't work for me because session.user doesn't have an accessToken property.
Is there something I'm missing either on the IdentityServer end or in the next-auth config?

[iaincollins]

The session returned to the client doesn't contain any accessTokens for OAuth providers in it by default.

To get the accessToken or refreshToken you can look it up from the accounts table and inject it into the session using the session() callback - you can try using callback and then looking at the response in /api/auth/session until it looks like it has the data you want. :-)

If you are using JSON Web Tokens things are actually simpler as they are persisted in the JWT on sign in and you can easily pass data from the JWT to the session using the session() callback

[iaincollins]

^ I get this isn't very clear BTW, it only landed today / last night; I plan to write up some examples of how to use the callbacks do stuff like this.

[iaincollins]

Closing this off as @geraldnolan added this recently - it will go out in the next release!

[RemiKalbe]

Coulnd't node-openid-client be used under the hood to support OIDC? You don't have to reinvent the wheel.