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.

Sign up for GitHub

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

Jump to bottom

Clarify language around discovering "jwks_uri". #115

Open
wants to merge 1 commit into
base: v1.0.x
Choose a base branch
from
Open

Clarify language around discovering "jwks_uri". #115

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/Behaviour - Resource Servers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,8 @@ Resource Servers SHOULD attempt to verify tokens against all keys presented at t
endpoint. All valid JWK's SHOULD be tried until the token is verified or until no keys are left.

Where a Resource Server has no matching public key for a given token, it SHOULD attempt to obtain the missing public key
via the the token `iss` claim as specified in [RFC 8414][RFC-8414] section 3. In cases where the Resource Server needs
from the Authorization Server's "jwks_uri" property, which is found in the server metadata. The server metadata can be obtained
from a URI based on the token's issuer (`iss`) claim as specified in [RFC 8414][RFC-8414] section 3. In cases where the Resource Server needs
to fetch a public key from a remote Authorization Server it MAY temporarily respond with an HTTP 503 code in order to
avoid blocking the incoming authorized request. When a HTTP 503 code is used, the Resource Server SHOULD include an
HTTP `Retry-After` header to indicate when the client may retry its request.
Expand Down