Using OpenID Connect in production, how to do full security checks

Crowdhailer

Creator of Raxx

I’m trying to set up an elixir application that uses OpenID connect for authentication. I don’t want to roll my own security so I am using the most popular library openid_connect which looks to be supported by Dockyard, or at least it’s on their github.

The instructions to use the library and verify the token are as follows.

Verify the JWT

The JWT is encrypted and it should always be verified with the JSON Web Keys (JWK) for the provider:
{:ok, claims} = OpenIDConnect.verify(:google, tokens["id_token"])
The claims is a payload with the information from the scopes you requested of the provider.

Read the claims and set your app’s user session

Now that you have the claims payload you can use the user data to identify and set the user’s session state for your app.
Setting your app’s session state is outside the scope of this library.

There are additional checks of an id_token that are required if using the implicit flow that are not performed by the verify function. Full list is available here. Final: OpenID Connect Core 1.0 incorporating errata set 2

Does anyone have a setup that does perform all the checks. Either code example or library form?

7 comments

/phoenix #security #deployment #oauth2

2 5291 7

2020-02-27 19:47:12 UTC

Showing Posts 1 to 7

Show Best Posts
Show All (oldest first)
Show All (newest first)

wolfiton

Have you looked at pow and pow_assent? GitHub - pow-auth/pow_assent: Multi-provider authentication for your Pow enabled app · GitHub

Post #1

Crowdhailer

Creator of Raxx

There is a lot of overhead in that library/ecosystem. There is understanding Pow/Assent/Assent strategies/OIDC itself. Ideally I would stick with a OpenID specific library as that is the only thing I need.

Post #2

danschultzer

Pow Core Team

Yeah, PowAssent has a lot of overhead. Assent is the low level multi provider library and it doesn’t have much overhead. Also compared to the OIDC library, it doesn’t require a particular JSON parser or HTTP client and uses config as function arg instead of application env.

Assent OIDC/OAuth2 only supports auth code flow, but for a good reason. Implicit code flow is discouraged in favor of auth code flow without client secret. PKCE is often used in this case.

I’ve most of the id token validations here: assent/lib/assent/strategies/oidc.ex at v0.1.5 · pow-auth/assent · GitHub

Post #3

Crowdhailer

Creator of Raxx

The implicit token flow has it’s usecases, it’s certainly useful for Single Page applications. I currently send the id token directly to the client, protected with PKCE, which is not too hard to do with the crypto capabilities in the browser.

Good to know because I guess that means I rule out Assent entirely.

Post #4

danschultzer

Pow Core Team

True, for SPA without a backend there are use cases, but then you wouldn’t need an Elixir client

PKCE is an extension for authorization code, and requires two request code exchange. It can’t be used for implicit flow, and AFAIK wouldn’t make sense for SPA since everything happens in the browser.

Here’s a memo that goes into implicit flow, including a list of threats: draft-ietf-oauth-browser-based-apps-00

Post #5

Crowdhailer

Creator of Raxx

@danschultzer does Assent work for self issued id_tokens Final: OpenID Connect Core 1.0 incorporating errata set 2

We make use of selfissued tokens at did.app so we can be an act as an Identity provider that can’t track every sign in a client makes

Post #6

danschultzer

Pow Core Team

Hey, sorry for the late response.

It doesn’t work with self issued id token since that requires implicit grant flow. Only auth code grant flow is supported, but I think this is something Assent OIDC strategy should be able to handle.

I’ll work on this: Support OIDC self issued id tokens · Issue #35 · pow-auth/assent · GitHub

Post #7

— All posts loaded —