diff --git a/docs/configuration/identity-providers/oidc.md b/docs/configuration/identity-providers/oidc.md index 3fa8be18..0f832fd5 100644 --- a/docs/configuration/identity-providers/oidc.md +++ b/docs/configuration/identity-providers/oidc.md @@ -16,132 +16,7 @@ social media or development platforms for login. The Relying Party role is the role which allows an application to use GitHub, Google, or other [OpenID Connect] providers for authentication and authorization. We do not intend to support this functionality at this moment in time. -## Roadmap - -We have decided to implement [OpenID Connect] as a beta feature, it's suggested you only utilize it for testing and -providing feedback, and should take caution in relying on it in production as of now. [OpenID Connect] and it's related -endpoints are not enabled by default unless you specifically configure the [OpenID Connect] section. - -As [OpenID Connect] is fairly complex (the [OpenID Connect] Provider role especially so) it's intentional that it is -both a beta and that the implemented features are part of a thoughtful roadmap. Items that are not immediately obvious -as required (i.e. bug fixes or spec features), will likely be discussed in team meetings or on GitHub issues before being -added to the list. We want to implement this feature in a very thoughtful way in order to avoid security issues. - -The beta will be broken up into stages. Each stage will bring additional features. The following table is a *rough* plan -for which stage will have each feature, and may evolve over time: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
StageFeature Description
beta1 (4.29.0)User Consent
Authorization Code Flow
OpenID Connect Discovery
RS256 Signature Strategy
Per Client Scope/Grant Type/Response Type Restriction
Per Client Authorization Policy (1FA/2FA)
Per Client List of Valid Redirection URI's
Confidential Client Type
beta2 (4.30.0)Userinfo Endpoint (missed in beta1)
Parameter Entropy Configuration
Token/Code Lifespan Configuration
Client Debug Messages
Client Audience
Public Client Type
beta3 1Token Storage
Audit Storage
beta4 1Prompt Handling
Display Handling
beta5 1Back-Channel Logout
Deny Refresh on Session Expiration
Signing Key Rotation Policy
Client Secrets Hashed in Configuration
GA 1General Availability after previous stages are vetted for bug fixes
miscList of other features that may be implemented
Front-Channel Logout 2
OAuth 2.0 Authorization Server Metadata 2
OpenID Connect Session Management 2
End-User Scope Grants 2
Client RBAC 2
Preferred Username Claim (implemented in 4.33.2)
- -¹ _This stage has not been implemented as of yet_. - -² _This individual feature has not been implemented as of yet_. - +More information about the beta can be found in the [roadmap](../../roadmap/oidc.md). ## Configuration diff --git a/docs/roadmap.md b/docs/roadmap/index.md similarity index 75% rename from docs/roadmap.md rename to docs/roadmap/index.md index d669e931..beb3fb3e 100644 --- a/docs/roadmap.md +++ b/docs/roadmap/index.md @@ -2,15 +2,14 @@ layout: default title: Roadmap nav_order: 9 +has_children: true --- -# Roadmap - -Currently the team consists of 3 globally distributed developers working actively on improving Authelia in our spare time and we define -our priorities based on a roadmap that we share here for transparency. We also try to balance features and improvements as much as possible with -the maintenance tasks we have to perform to keep the backlog of open issues in a reasonable state. -If you're willing to contribute and help us move forward faster, get in touch with us on Matrix. We'll be glad to share -ideas and plans with you. +The Authelia team consists of 3 globally distributed developers working actively on improving Authelia in our spare time +and we define our priorities based on a roadmap that we share here for transparency. We also try to balance features and +improvements as much as possible with the maintenance tasks we have to perform to keep the backlog of open issues in a +reasonable state. If you're willing to contribute and help us move forward faster, get in touch with us on Matrix. We'll +be glad to share ideas and plans with you. Below are the prioritised roadmap items: @@ -22,10 +21,8 @@ priority because currently the only way to pass authentication information back use of HTTP headers as described [here](https://www.authelia.com/docs/deployment/supported-proxies/#how-can-the-backend-be-aware-of-the-authenticated-users) however, many apps either do not support this method or are starting to move away from this in favour of OpenID Connect or OAuth2 -internally or via plugins. - -**[In Preview](./configuration/identity-providers/oidc.md)** *this roadmap item is in preview status since information -is not yet persisted in the database. More information can be found in the docs*. +internally or via plugins. **[In Preview](./oidc.md)** *this roadmap item is in preview status since information is not +yet persisted in the database. More information can be found [here](./oidc.md) in the docs*. 3. [Multilingual full support](https://github.com/authelia/authelia/issues/625). Support as been added but we heed to study multiple providers like Crowdin or Weblate to help us translate in more languages and make Authelia available to even more people around the world! @@ -41,7 +38,7 @@ kill sessions to reduce security risk due to compromised accounts and many other items for implementing the features but there is preparatory work to be done on the permissions (likely role-based) we want to implement. -7. [Facilitate setup on Kubernetes](https://github.com/authelia/authelia/issues/575). There are mainly two objectives +6. [Facilitate setup on Kubernetes](https://github.com/authelia/authelia/issues/575). There are mainly two objectives here. First, we need to provide the documentation required to setup Authelia on Kubernetes. Even though, some users already have it working and the feature is even tested in the project, there is a clear lack of documentation. The second item is to provide a Helm chart to streamline the setup on Kubernetes. diff --git a/docs/roadmap/oidc.md b/docs/roadmap/oidc.md new file mode 100644 index 00000000..ac0c7fc7 --- /dev/null +++ b/docs/roadmap/oidc.md @@ -0,0 +1,138 @@ +--- +layout: default +title: OpenID Connect +parent: Roadmap +nav_order: 1 +--- + +We have decided to implement [OpenID Connect] as a beta feature, it's suggested you only utilize it for testing and +providing feedback, and should take caution in relying on it in production as of now. [OpenID Connect] and it's related +endpoints are not enabled by default unless you specifically configure the [OpenID Connect] section. + +As [OpenID Connect] is fairly complex (the [OpenID Connect] Provider role especially so) it's intentional that it is +both a beta and that the implemented features are part of a thoughtful roadmap. Items that are not immediately obvious +as required (i.e. bug fixes or spec features), will likely be discussed in team meetings or on GitHub issues before being +added to the list. We want to implement this feature in a very thoughtful way in order to avoid security issues. + +The beta will be broken up into stages. Each stage will bring additional features. The following table is a *rough* plan +for which stage will have each feature, and may evolve over time: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StageFeature Description
beta1 (4.29.0)User Consent
Authorization Code Flow
OpenID Connect Discovery
RS256 Signature Strategy
Per Client Scope/Grant Type/Response Type Restriction
Per Client Authorization Policy (1FA/2FA)
Per Client List of Valid Redirection URI's
Confidential Client Type
beta2 (4.30.0)Userinfo Endpoint (missed in beta1)
Parameter Entropy Configuration
Token/Code Lifespan Configuration
Client Debug Messages
Client Audience
Public Client Type
beta3 (4.34.0)Proof Key for Code Exchange (PKCE) for Authorization Code Flow
beta4 1Token Storage
Audit Storage
beta5 1Prompt Handling
Display Handling
beta6 1Back-Channel Logout
Deny Refresh on Session Expiration
Signing Key Rotation Policy
Client Secrets Hashed in Configuration
UUID or Random String for sub claim
GA 1General Availability after previous stages are vetted for bug fixes
miscList of other features that may be implemented
Front-Channel Logout 2
OAuth 2.0 Authorization Server Metadata 2
OpenID Connect Session Management 2
End-User Scope Grants 2
Client RBAC 2
Add preferred_username claim (4.33.2)
+ +¹ _This stage has not been implemented as of yet_. + +² _This individual feature has not been implemented as of yet_. +