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

V51 OAuth: Add new OIDC Client verifications #2048

Closed
TobiasAhnoff opened this issue Aug 31, 2024 · 8 comments
Closed

V51 OAuth: Add new OIDC Client verifications #2048

TobiasAhnoff opened this issue Aug 31, 2024 · 8 comments
Assignees
Labels
1) Discussion ongoing Issue is opened and assigned but no clear proposal yet 2) Awaiting response Awaiting a response from the original poster V51 Group issues related to OAuth _5.0 - prep This needs to be addressed to prepare 5.0

Comments

@TobiasAhnoff
Copy link

The following verifications are suggested to be added for the client to the proposed new OIDC chapter (see #2037).

Client

Verify that in addition to regular JWT validation, ID tokens are validated to have 'aud' equal to the client id and a short lifetime (e g 1 minute).

Verify that if the 'id-token' grant is used then nonce validation must be performed on authorization respones.

@elarlang elarlang added the V51 Group issues related to OAuth label Aug 31, 2024
@randomstuff
Copy link
Contributor

FWIW, Keycloak, for example, currently sends ID token which are valid for 5 minutes by default. 1 minute might be a little bit drastic. While I agree that ID tokens are expected to be short-lived, adding this verification might lead to broken OIDC communications.

What is the intend of this verification in the client? If the goal is to avoid ID token reuse, would it be better to request a fresh enough OIDC in the client (using the max_age parameter) and checking that the ID token auth_time is consistent?

@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 Sep 2, 2024
@elarlang elarlang changed the title V5.1 OAuth: Add new OIDC Client verifications V51 OAuth: Add new OIDC Client verifications Sep 10, 2024
@elarlang
Copy link
Collaborator

elarlang commented Sep 13, 2024

Verify that in addition to regular JWT validation, ID tokens are validated to have 'aud' equal to the client id and a short lifetime (e g 1 minute).

  • "in addition to regular JWT validation" - this part does not give anything extra
  • checking aud and life-time are different checks and have different goal, so I think it makes sense to have separate requirement for them

Wordsmithing needed, but the style and direction should be:

Verify that the ID-token is made for the Client by validating the aud claim value to be equal with the client id.

The requirement expects client id to be unique, so that also sets one general requirement as pre-conditon:

Verify that OAuth / OIDC Client is unique and used only by the application.

Discussion for this should be carried here: #2043 (comment)


What problem we need to solve with short id-token lifetime? From where comes proposal for 1minute (is it backed up somewhere in RFC or OIDC spec)


Verify that if the 'id-token' grant is used then nonce validation must be performed on authorization respones.

In case it is meant to be against replay attacks, then maybe

Verify that the application is protected against ID-token replay attacks by validating the nonce claim.

We have duplicate discussion over this in #2002

@TobiasAhnoff
Copy link
Author

FWIW, Keycloak, for example, currently sends ID token which are valid for 5 minutes by default. 1 minute might be a little bit drastic. While I agree that ID tokens are expected to be short-lived, adding this verification might lead to broken OIDC communications.

@randomstuff I agree on 5 min (not 1) e g Duende and Curity Identity Server also has 5 min as default for ID tokens.

@elarlang
Copy link
Collaborator

For documenting things - can you clarify the risk here as well - why it is important to have a short-lived ID-token and what security problem it solves?

@elarlang
Copy link
Collaborator

elarlang commented Sep 15, 2024

"Check the aud" is also covered in:

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.

The requirement itself is under discussion in #1967

@TobiasAhnoff
Copy link
Author

For documenting things - can you clarify the risk here as well - why it is important to have a short-lived ID-token and what security problem it solves?

This is to encourage the intended purpose of the ID token, as discussed in #2005, a short-lived ID token (with aud equal to the client id) is harder to reuse as an access token, and ID tokens in particular are more often than access-tokens exposed to the front-end, i e when using the OIDC id-token or hybrid flow.

Verify that in addition to regular JWT validation, ID tokens are validated to have 'aud' equal to the client id and a short lifetime (e g 5 minutes)

This could be considered to detailed and covered (duplicated) by #2005

Verify that tokens (such as ID tokens, access tokens and refresh tokens) can only be used according to their intended purpose without allowing cross-usage between them. In example ID tokens cam only be used to prove user authentication for the client.

@elarlang
Copy link
Collaborator

Verify that in addition to regular JWT validation, ID tokens are validated to have 'aud' equal to the client id and a short lifetime (e g 1 minute).

Previously linked #2005 is now in the document, but I'm not sure it covers the idea for this requirement.

We also have other issues:

Verify that if the 'id-token' grant is used then nonce validation must be performed on authorization respones.

I think it is duplicate of issue #2002

If you agree that those topic are covered linked issues, we can close this one.

@elarlang elarlang added the 2) Awaiting response Awaiting a response from the original poster label Sep 18, 2024
@TobiasAhnoff
Copy link
Author

Yes, I think this one can be closed since it is covered by #2002 and #2005

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 2) Awaiting response Awaiting a response from the original poster 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

4 participants