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?
2 Likes
Have you looked at pow and pow_assent? https://github.com/pow-auth/pow_assent
1 Like
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.
1 Like
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: https://github.com/pow-auth/assent/blob/v0.1.5/lib/assent/strategies/oidc.ex#L212-L223
1 Like
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.
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: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-00#section-9.8
1 Like
@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
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: https://github.com/pow-auth/assent/issues/35
1 Like
