Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

review V51.4.2 #2182

Open
elarlang opened this issue Oct 22, 2024 · 3 comments
Open

review V51.4.2 #2182

elarlang opened this issue Oct 22, 2024 · 3 comments
Labels
1) Discussion ongoing Issue is opened and assigned but no clear proposal yet V51 Group issues related to OAuth _5.0 - prep This needs to be addressed to prepare 5.0

Comments

@elarlang
Copy link
Collaborator

elarlang commented Oct 22, 2024

From the initial OAuth paragraph draft we have requirements:

# Description L1 L2 L3
51.4.2 [ADDED] Verify that access tokens are restricted to certain resource servers (audience restriction), preferably to a single resource server. Every resource server is obliged to verify, for every request, whether the access token sent with that request was meant to be used for that particular resource server. If not, the resource server must refuse to serve the respective request.

Additionally to some formating improvements, we need to (re)validate the content, the need, the problem to solve and sections.

@elarlang elarlang added the V51 Group issues related to OAuth label Oct 22, 2024
@elarlang elarlang changed the title review V51.4.2 and V51.4.3 review V51.4.2 Oct 22, 2024
@tghosth tghosth added 1) Discussion ongoing Issue is opened and assigned but no clear proposal yet _5.0 - prep This needs to be addressed to prepare 5.0 labels Oct 22, 2024
@elarlang
Copy link
Collaborator Author

We have also requirement 3.5.6:

# Description L1 L2 L3 CWE
3.5.6 [ADDED] Verify that other, security-sensitive attributes of a stateless token are being verified. For example, in a JWT this may include issuer, subject, and audience. 287

Maybe we should cover it with spliting 3.5.6 to more precise requirements, as recommended in #1967 (comment).

At the same time I don't want the message to be hidden, that aud in an access token points to resource server and aud in ID token points to client_id.

@randomstuff
Copy link

randomstuff commented Oct 23, 2024

preferably to a single resource server.

FWIW, this condition is less important (sometimes) when using sender-constrained tokens.

@elarlang
Copy link
Collaborator Author

For direction:

Verify that the resource server validates the access token to be made for that resource server (audience) by checking the 'aud' claim from the access token to be an expected value.

Need to cover:

  • reference token and introspection
  • fix the last part - the aud need to contain expected value referencing to resource server

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1) Discussion ongoing Issue is opened and assigned but no clear proposal yet V51 Group issues related to OAuth _5.0 - prep This needs to be addressed to prepare 5.0
Projects
None yet
Development

No branches or pull requests

3 participants