View in #general on Slack
@Christian_Svensson:
Hello, I’m a happy user of Pomerium! I’m considering switching from using GitHub to another IdP called Freja eID. They are a heavy-duty IdP for citizen authentication in Sweden, think authentication towards government branches and healthcare. Either way, they implement OIDC - but require a bit of mangling on the last step to extract the usable user information. Specifically, they seem to return a signed JWT, so in order to extract e.g. email or username one needs to validate and parse that token. While I could simply accept any successful login (which is every citizen in Sweden) and punt the authorization to the backend, I would of course love to do it in Pomerium.
Is that possible with Pomerium today? I know in ngnix I can offload similar operations using auth_request. Maybe there is something similar for Pomerium, or on the roadmap?
Reading a bit more about OIDC after typing this out, it seems there is a “Userinfo” phase which might match what I want. I couldn’t find anything in Pomeriums documentation about it though - but https://github.com/pomerium/pomerium/blob/master/internal/identity/oidc/userinfo.go seems useful. Maybe this all “just works”?
After trying it and hacking one bug I found in Pomerium, it indeed “Just works”! It was my understanding of OIDC UserInfo that was lacking 
@Bobby:
Hello, I’m a happy user of Pomerium!
Hey @Christian_Svensson 
! Glad to hear it 
IdP called Freja eID
Super interesting! I had never heard of this before. And, I love Sweden already for adopting OIDC.
After trying it and hacking one bug I found in Pomerium,
That issue is being tracked on github:
Unable to use `oidc` when `access_type` is not allowed to be set · Issue #2773 · pomerium/pomerium · GitHub
Otherwise, Pomerium e should be doing the right thing to grab additional data from the user info endpoint as described in OIDC RFC (5.3).
At a super high level, our auth process looks like this for oidc.
- user tries to access a pomerium endpoint without a session (or expired)
- Pomerium redirects the user to the IdP to complete sso
- user logs in via idp
- user is return to pomerium’s authenticate service with a
code
- pomerium exchanges the
code to get an: access_token , id_token and refresh_token.
- Pomerium builds the user’s session context from the
id_token first (depending on the IdP this can be quite a few claims, or just the barebones required ones. The id_token is a signed JWT. I think this is what you are referencing. We do parse and verify the cryptographic signature of this token listed in on the IdPs well-known openid-connect doc.
- Pomerium makes an additional request to the user_info endpoint as specified in the well-known openid-connect doc. Pomerium uses the
access_token as an Authorization bearer token from the previous step to authenticate against that endpoint which returns a JSON response to further enrich the user’s session data.
If there is anything custom about the identity provider, we’d be happy to accept a PR for it as an IdP configuration (sometimes the IdPs are quirky in how they actually follow the spec) since this sounds like a major one.
@Christian_Svensson – hopefully that answer is helpful. Would you mind if we posted this to our discuss page for future folks?
@Christian_Svensson:
Sorry that I noticed your reply so late, but yes - feel free to post it!
Yes, OIDC vanilla worked just fine as you mentioned - I only had problems with the online/offline as you know
