mirror/keycloak
1
0
Fork 0
mirror of https://github.com/keycloak/keycloak.git synced 2026-05-03 21:50:47 -05:00
Code Issues Packages Projects Releases Wiki Activity

update links to OAuth 2.1 draft spec and change link from BCP to RFC9700

Browse Source 
closes #40419

Signed-off-by: Niko Köbler <niko@n-k.de>
This commit is contained in:
Niko Köbler
2025-06-11 18:48:43 +02:00
committed by GitHub
parent 8e0747571f
commit 2e7a88f052
2 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/guides/securing-apps/partials/oidc/oauth21-support.adoc
+1 -1
View File
@@ -3,7 +3,7 @@
{project_name} makes it easier for administrators to make sure that their clients are compliant with these specifications:
* https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-10[The OAuth 2.1 Authorization Framework - draft specification]
* https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13[The OAuth 2.1 Authorization Framework - draft specification]
This compliance means that the {project_name} server will verify the requirements
for the authorization server, which are mentioned in the specifications. {project_name} adapters do not have any specific support for the OAuth 2.1, hence the required validations on the client (application)
docs/guides/securing-apps/partials/oidc/supported-grant-types.adoc
+5 -5
View File
@@ -28,15 +28,15 @@ browser history. You can somewhat mitigate this problem by using short expiratio
For more details, see the https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth[Implicit Flow] in the OpenID Connect specification.
Per current https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-implicit-grant[OAuth 2.0 Security Best Current Practice], this flow should not be used.
This flow is removed from the future https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-09[OAuth 2.1 specification].
Per current https://datatracker.ietf.org/doc/html/rfc9700#name-implicit-grant[Best Current Practice for OAuth 2.0 Security (RFC 9700)], this flow SHOULD NOT be used.
This flow is removed from the future https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13[OAuth 2.1 specification].
[[_resource_owner_password_credentials_flow]]
=== Resource Owner Password Credentials
Resource Owner Password Credentials, referred to as Direct Grant in {project_name}, allows exchanging user credentials for tokens.
Per current https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-resource-owner-password-cre[OAuth 2.0 Security Best Practices],
this flow should not be used, preferring alternative methods such as <<Device Authorization Grant>> or <<Authorization code>>.
Per current https://datatracker.ietf.org/doc/html/rfc9700#name-resource-owner-password-cre[Best Current Practice for OAuth 2.0 Security (RFC 9700)],
this flow MUST NOT be used, preferring alternative methods such as <<Device Authorization Grant>> or <<Authorization code>>.
The limitations of using this flow include:
@@ -56,7 +56,7 @@ Security concerns with this flow include:
For a client to be permitted to use the Resource Owner Password Credentials grant, the client has to have the `Direct Access Grants Enabled` option enabled.
This flow is not included in OpenID Connect, but is a part of the OAuth 2.0 specification.
It is removed from the future https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-09[OAuth 2.1 specification].
It is removed from the future https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13[OAuth 2.1 specification].
For more details, see the https://datatracker.ietf.org/doc/html/rfc6749#section-4.3[Resource Owner Password Credentials Grant] chapter in the OAuth 2.0 specification.