+V10.4 OAuth Authorization Server
---+V10.4.1 Verify that the authorization server validates redirect URIs based on a client-specific allowlist …
---+V10.4.2 Verify that, if the authorization server returns the authorization code in the authorization …
---+V10.4.3 Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for …
---+V10.4.4 Verify that for a given client, the authorization server only allows the usage of grants that this …
---+V10.4.5 Verify that the authorization server mitigates refresh token replay attacks for public clients …
---+V10.4.6 Verify that, if the code grant is used, the authorization server mitigates authorization code …
---+V10.4.7 Verify that if the authorization server supports unauthenticated dynamic client registration, it …
---+V10.4.8 Verify that refresh tokens have an absolute expiration, including if sliding refresh token …
---+V10.4.9 Verify that refresh tokens and reference access tokens can be revoked by an authorized user using …
---+V10.4.10 Verify that confidential client is authenticated for client-to-authorized server backchannel …
---+V10.4.11 Verify that the authorization server configuration only assigns the required scopes to the OAuth …
---+V10.4.12 Verify that for a given client, the authorization server only allows the 'response_mode' value that …
---+V10.4.13 Verify that grant type 'code' is always used together with pushed authorization requests (PAR).
---+V10.4.14 Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access …
---+V10.4.15 Verify that, for a server-side client (which is not executed on the end-user device), the …
---+V10.4.16 Verify that the client is confidential and the authorization server requires the use of strong …
|
V10.4 OAuth Authorization Server
These requirements detail the responsibilities for OAuth authorization servers, including OpenID Providers. For client authentication, the 'self_signed_tls_client_auth' method is allowed with the prerequisites required by section 2.2 of RFC 8705.
1. Áttekintés
| Megnevezés |
Szabvány |
|
V10.4.1 Verify that the authorization server validates redirect URIs based on a client-specific allowlist …
|
Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison.
|
|
V10.4.2 Verify that, if the authorization server returns the authorization code in the authorization …
|
Verify that, if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the second valid request with an authorization code that has already been used to issue an access token, the authorization server must reject a token request and revoke any issued tokens related to the authorization code.
|
|
V10.4.3 Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for …
|
Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications.
|
|
V10.4.4 Verify that for a given client, the authorization server only allows the usage of grants that this …
|
Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must no longer be used.
|
|
V10.4.5 Verify that the authorization server mitigates refresh token replay attacks for public clients …
|
Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens, i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens using mutual TLS (mTLS). For L1 and L2 applications, refresh token rotation may be used. If refresh token rotation is used, the authorization server must invalidate the refresh token after usage, and revoke all refresh tokens for that authorization if an already used and invalidated refresh token is provided.
|
|
V10.4.6 Verify that, if the code grant is used, the authorization server mitigates authorization code …
|
Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring proof key for code exchange (PKCE). For authorization requests, the authorization server must require a valid 'code_challenge' value and must not accept a 'code_challenge_method' value of 'plain'. For a token request, it must require validation of the 'code_verifier' parameter.
|
|
V10.4.7 Verify that if the authorization server supports unauthenticated dynamic client registration, it …
|
Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It must validate client metadata such as any registered URIs, ensure the user's consent, and warn the user before processing an authorization request with an untrusted client application.
|
|
V10.4.8 Verify that refresh tokens have an absolute expiration, including if sliding refresh token …
|
Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied.
|
|
V10.4.9 Verify that refresh tokens and reference access tokens can be revoked by an authorized user using …
|
Verify that refresh tokens and reference access tokens can be revoked by an authorized user using the authorization server user interface, to mitigate the risk of malicious clients or stolen tokens.
|
|
V10.4.10 Verify that confidential client is authenticated for client-to-authorized server backchannel …
|
Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, pushed authorization requests (PAR), and token revocation requests.
|
|
V10.4.11 Verify that the authorization server configuration only assigns the required scopes to the OAuth …
|
Verify that the authorization server configuration only assigns the required scopes to the OAuth client.
|
|
V10.4.12 Verify that for a given client, the authorization server only allows the 'response_mode' value that …
|
Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. For example, by having the authorization server validate this value against the expected values or by using pushed authorization request (PAR) or JWT-secured Authorization Request (JAR).
|
|
V10.4.13 Verify that grant type 'code' is always used together with pushed authorization requests (PAR).
|
Verify that grant type 'code' is always used together with pushed authorization requests (PAR).
|
|
V10.4.14 Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access …
|
Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access tokens, either with certificate-bound access tokens using mutual TLS (mTLS) or DPoP-bound access tokens (Demonstration of Proof of Possession).
|
|
V10.4.15 Verify that, for a server-side client (which is not executed on the end-user device), the …
|
Verify that, for a server-side client (which is not executed on the end-user device), the authorization server ensures that the 'authorization_details' parameter value is from the client backend and that the user has not tampered with it. For example, by requiring the usage of pushed authorization request (PAR) or JWT-secured Authorization Request (JAR).
|
|
V10.4.16 Verify that the client is confidential and the authorization server requires the use of strong …
|
Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), such as mutual TLS ('tls_client_auth', 'self_signed_tls_client_auth') or private key JWT ('private_key_jwt').
|
1.1 Hivatkozások
1.2 Azonosított követelmények
1.3 Kapcsolódó szabályozások
2. Azonosított követelmények
Követelmények
| Forrás |
Követelmény |
3. Kapcsolódó szabályozások
Szabályozások
| Forrás |
Szabályozás |
- OWASP -
EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative. - OWASP Application Security Verification Standard (ASVS) 5.0.0, May 2025, from OWASP/ASVS: © 2008-2025 The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: divided into sections and converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0, January 2024, from OWASP/masvs: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0, August 2026, from OWASP/maswe: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged, linked to the MASVS controls they map to. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0, June 2026, from OWASP/mastg: © The OWASP Foundation, licensed under CC BY-SA 4.0. The tests and best practices only, without code samples, images, tools or apps. Changes: converted into the GRCA format, the wording unchanged; references to other pages of the MASTG as links to mas.owasp.org; the weakness of each test in the numbering of MASWE v1 and linked to it. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Software Assurance Maturity Model (SAMM) v2.2.0, July 2026, from owaspsamm/core: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged; short codes (G-SM-1-A) built from the model, the assessment questions as assessment procedures of their activities. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Top 10:2025, from OWASP/Top10: © 2003-2025 The OWASP® Foundation, Inc., licensed under CC BY-SA 4.0. The ten categories, without the icons. Changes: converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well. The names of the mapped CWEs (Common Weakness Enumeration): © 2006–2026 The MITRE Corporation. License: The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. See the CWE Terms of Use. CWE™ is a trademark of The MITRE Corporation.
DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen. - OWASP Application Security Verification Standard (ASVS) 5.0.0, Mai 2025, aus OWASP/ASVS: © 2008-2025 The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in Abschnitte aufgeteilt und in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0, Januar 2024, aus OWASP/masvs: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0, August 2026, aus OWASP/maswe: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert, mit den MASVS-Controls verknüpft, denen sie zugeordnet sind. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0, Juni 2026, aus OWASP/mastg: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Nur die Tests und Best Practices, ohne Codebeispiele, Bilder, Werkzeuge und Apps. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert; Verweise auf andere Seiten des MASTG als Links zu mas.owasp.org; die Schwachstelle jedes Tests in der Nummerierung der MASWE v1 und mit ihr verknüpft. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Software Assurance Maturity Model (SAMM) v2.2.0, Juli 2026, aus owaspsamm/core: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert; Kürzel (G-SM-1-A) aus dem Modell gebildet, die Assessment-Fragen als Prüfverfahren ihrer Aktivitäten. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Top 10:2025, aus OWASP/Top10: © 2003-2025 The OWASP® Foundation, Inc., lizenziert unter CC BY-SA 4.0. Die zehn Kategorien, ohne die Symbole. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0. Die Namen der zugeordneten CWEs (Common Weakness Enumeration): © 2006–2026 The MITRE Corporation. MITRE erlaubt die Nutzung für Forschung, Entwicklung und kommerzielle Zwecke, wenn jede Kopie den Urheberrechtsvermerk und die Lizenz enthält; maßgeblich ist der englische Wortlaut der Lizenz oben und die CWE Terms of Use. CWE™ ist eine Marke der MITRE Corporation.
|