-
Notifications
You must be signed in to change notification settings - Fork 327
Flow Chart
An unauthenticated user is redirected to the Provider with an authentication request tracked by a state cookie, unless other behaviour is configured with OIDCUnAuthAction
.
After authentication at the Provider, the user is redirected back to the OIDCRedirectURI
where - after validating the state cookie - mod_auth_openidc exchanges the authorization code for an id_token
, an access_token
and possibly a refresh_token
.
The claims returned by the Provider in the id_token
and the userinfo
endpoint are filtered according to the blacklist/whitelist filter and subsequently -if configured - processed by the OIDCFilterClaimsExpr
, the resulting set of claims is stored in the session.
A session is created for the authenticated user that is stored in the cache and tracked by a session cookie. Stored with the session are the claims, a max lifetime timer, inactivity timer, etc. The user is then redirected back to the original URL that he wanted to access whilst setting a session cookie and deleting the state cookie.
Upon application access with a session cookie, mod_auth_openidc will authorize the user according to the Require
directives and the behaviour configured by OIDCUnAutzAction
. This may lead to a 401 Unauthorized or another redirect (back to 1.) in case of stepup authentication.
When the authentication and authorization has checked out, the module will pass claims to the application in the form of environment variables and/or - in case of proxying to a backend - HTTP headers. This behaviour is configured with OIDCPassClaimsAs
and OIDCPassIDTokenAs
. Filtering and processing for the claims from the userinfo endpoint (and not filtered out earlier) can be applied before propagating them with OIDCUserInfoClaimsExpr
after which OIDCPassUserInfoAs
is applied to send the claims in specific formats.