feat: add OpenID Connect (OIDC) provider

[larsrickert]

closes #25
closes #89

This PR adds support for a generic OpenID connect (OIDC) provider that can be used with any provider that supports the OIDC standard.

It supports the 'code' response type and grant type 'authorization_code'. If a client secret is provided, it will be used to fetch the token. Otherwise the PKCE flow will be used where no client secret is needed.

Since the existing PR #25 has not seen progress in almost two years, this PR is intended to replace #25.

Example usage

# .env
NUXT_OAUTH_OIDC_CLIENT_ID=your-client-id
NUXT_OAUTH_OIDC_OPENID_CONFIG=https://my-provider.com/.well-known/openid-configuration

// server/routes/auth/oidc.ts
export default defineOAuthOidcEventHandler({
  config: {
    scope: ['openid', 'profile', 'email'],
  },
  async onSuccess(event, { user }) {
    await setUserSession(event, {
      user: {
        oidc: user.name,
      },
      loggedInAt: Date.now(),
    })

    return sendRedirect(event, '/')
  },
})

[randriese]

this part does not seem to omit itself when a clientSecret is provided, resulting in a 400 Bad Request error when fetching the tokens.

[larsrickert]

In line 269 the verifier is set to undefined if a client secret is passed so its omitted in this case.

For me using a client secret works as expected 🤔 Which OIDC provider are you using?

[randriese]

using a client_secret works indeed, however I need to comment out line 300 even though the verifier returns undefined. I'm using the Surfconext OIDC provider and that one returns with a 'bad request' if the code_verifier is submitted as undefined in the request. Commenting out the line solved the issue.

[larsrickert]

Thanks for testing! I updated the implementation to only include the PKCE query parameters if the client ID is unset.
Would you mind testing it again?

[randriese]

Works as expected now!

[Natronick]

Hi @larsrickert ! Great work.
Are you considering the possibility of retrieving user data by validating and decoding the ID token if it's provided by the provider (alongside the Access token)?

[randriese]

Hi @larsrickert ! Great work.

Are you considering the possibility of retrieving user data by validating and decoding the ID token if it's provided by the provider (alongside the Access token)?

That's already implemented :)

[Natronick]

Hi @larsrickert ! Great work.
Are you considering the possibility of retrieving user data by validating and decoding the ID token if it's provided by the provider (alongside the Access token)?

That's already implemented :)

Thanks for the quick reply! Could you point me to where this is implemented? I'm not seeing it in the PR code. Currently, it seems we only retrieve user info via the userinfo endpoint (which is optional), and the OidcTokens interface doesn't contain the idToken. Maybe I'm missing something?

[randriese]

Hi @larsrickert ! Great work.

Are you considering the possibility of retrieving user data by validating and decoding the ID token if it's provided by the provider (alongside the Access token)?

That's already implemented :)

Thanks for the quick reply! Could you point me to where this is implemented? I'm not seeing it in the PR code. Currently, it seems we only retrieve user info via the userinfo endpoint (which is optional), and the OidcTokens interface doesn't contain the idToken. Maybe I'm missing something?

Maybe I misunderstood? As far a I saw during testing the user data is decoded in this server route which is used when redirecting from the oidc provider back to the Frontend.

playground/server/routes/auth/oidc.ts

[larsrickert]

Maybe I misunderstood? As far a I saw during testing the user data is decoded in this server route which is used when redirecting from the oidc provider back to the Frontend.

Yes the user data is retrieved by sending the access token to the userinfo endpoint of the OIDC provider (thats already implemented). There is also a second way how the user data could be retrieved (e.g. because some providers do not offer a userinfo endpoint) and thats by requesting an idtoken (JWT with user data encoded in it) that is then validated and decoded.

I'd suggest to aleady merge the OIDC provider as it is so its not blocked by another optional feature :) We can then extend it if needed in follow up PRs