Title here
Summary here
OpenID Connect 1.0 Relying Party
The OpenID Connect 1.0 Relying Party role is often described as the client. Effectively the relying party relies on an OpenID Connect 1.0 Provider for authentication and authorization information, delegating the validation to the Provider.
Anchoring Implementation
needs design
For the OpenID Connect 1.0 Relying Party implementation to operate users must be able to anchor their Provider account
to their Relying Party account (i.e. Authelia). To do this the likely implementation will require the user to already be
authenticated to a level that satisfies the two_factor policy and for them to click a link to onboard them.
The accounts will then likely be linked using the pairwise iss and sub claims, i.e. issuer and subject identifier
respectively.
See the FAW for an explainer on why we’ve chosen these claims.
Authorization Implementation
needs design
To identify the user on an authorization attempt will likely be completed using the pairwise iss and sub claims,
i.e. issuer and subject identifier respectively as previously anchored.
This will very likely appear to the user similar to how the Login with Passkey button appears. There may be some customization provided as to how the layout occurs, i.e. either individually, in a menu, or a combination of the two.
Authentication Methods Reference Values
needs design
The Authentication Methods Reference Values could theoretically be used to derive the effective authentication level of the user in combination with Granular Authorization. We will likely implement this with a opt-in setting to trust the Provider.