Explore: evaluate OIDC/OAuth2 authentication flows

[gcapizzi]

Background

OpenID Connect 1.0, which is built on top of OAuth 2.0, supports three authentication flows:

• The Authorization Code flow, based on the OAuth 2.0 Authorization Code grant type.
• The Implicit flow, based on the OAuth 2.0 Implicit grant type.
• The Hybrid flow, which we don't think is interesting to us.

We want to understand which one is the best suited for our oidc-login implementation. Some notes:

• With the Implicit flow, the authorization token is returned to the client directly as part of the redirect URL. This is risky, so the flow has been deprecated.
• The Implicit flow does not support refresh tokens.
• With the Authorization Code flow, the redirect only contains an authorization code, which then needs to be exchanged for a token via a separate call from the client to the authorization server. This is more secure as the client needs to authenticate to the server using client credentials (a client_id and a client_secret), and the browser never gets to see the token. Unfortunately, this is only beneficial to server-side apps ("confidential clients") that can securely store the client credentials. Client-side apps ("public clients") can't, so this flow ends up being pretty much as secure as the Implicit one.
• An extension to the Authorization Code flow called Proof Key for Code Exchange (PKCE) has been introduced, which replaces client credentials with a secure system to correlate the token exchange request with the initial authorization request.

Questions

• How hard is it to implement oidc-login with Authorization Code + PKCE?
• How well is the PKCE extension supported by the major OIDC providers?
• Is it worth it to go for Authorization Code + PKCE?
• If we decide to use the Implicit flow instead, how bad would it be to give up refresh tokens? How long do authentication tokens usually last for?

Resources

• From the Implicit flow to PKCE: A look at OAuth 2.0 in SPAs
• What's going on with the OAuth 2.0 Implicit flow?
• OAuth 2.0 Simplified
• OAuth.net

Dev Notes

• Implementing PKCE seems easy and shouldn't need any external dependency to generate the challenge/verifier pair (example).
• Sending the PKCE challenge is supported by golang.org/x/oauth2.

[georgethebeatle]

So far we have managed to implement 2 oidc flows

• the Authorization flow with PKCE
• the original Authorization flow (with client secret)

We have tested both against dex (instructions here)

Both flows are supported by the same cf cli plugin based on whether you pass in a client secret or not.

We wanted to test the implicit grant flow as well, but it looks like it is not supported by kubernetes, since when you configure the apiserver to work with oidc, the oidc-client-id is a required parameter: https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server

[gcapizzi]

We wanted to test the implicit grant flow as well, but it looks like it is not supported by kubernetes

@georgethebeatle the Implicit flow still requires client_id ID to be passed in the authorization request.

[mnitchev]

We implemented the implicit flow for the cli plugin which had a few caveats:

• you need to set the response_type parameter to id_token
• you need to enable it in dex using the responseTypes configuration
• you are required to send a nonce parameter (which is some random string data) and then verify it in the response token [1]. We do not do this as part of this spike as it seemed trivial
• the returned token is inside the fragment [2][3] of the url, which stays inside the browser [4] and does not get forwarded to the local http server of the cli

To solve the last problem, we serve a static HTML page with some javascript to extract the token and send it as a query param to the server.

References:

1. https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes
2. https://openid.net/specs/openid-connect-core-1_0.html#ImplicitCallback
3. https://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthResponse
4. https://datatracker.ietf.org/doc/html/rfc3986#section-3.5

[mnitchev]

As a conclusion - we think that the PKCE flow is the best one and the most suited to use in the cli. However we can also have all of the other flows implemented in the plugin for whoever needs them, and have PKCE as default.

[kieron-dev]

It is recommended for IDPs to issue short-lived tokens with refresh tokens for better security. This gives the IDP the opportunity to stop access for a given user, effectively revoking the token. Okta suggests a short lived token might be issued for several hours. It also points out the bad user experience using short-lived tokens without refresh tokens, while noting long-lived tokens are problematic for security.

The expiry time of a token is up to configuration in the IDP, i.e. outside of our control. Therefore we should definitely support refresh tokens to avoid a bad user experience when IDP configuration provides short-lived tokens.

If we want to support the implicit flow, tokens will need to be longer-lived, and we should document the potential security issues with harder revocation and more damage on leakage.