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

Clarify language around discovering "jwks_uri". #115

Merged
merged 2 commits into from
Dec 5, 2024
Merged

Clarify language around discovering "jwks_uri". #115

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
971840a
Tweak language
jonathan-r-thorpe Nov 13, 2024
a658eb6
Remove spurious apostrophe.
jonathan-r-thorpe Dec 4, 2024
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
5 changes: 3 additions & 2 deletions docs/Behaviour - Resource Servers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,10 +19,11 @@ If a Resource Server is unable to contact an Authorization Server, the Resource
public keys remain valid until it is able to re-establish a connection to an Authorization Server.

Resource Servers SHOULD attempt to verify tokens against all keys presented at the Authorization Server's public key
endpoint. All valid JWK's SHOULD be tried until the token is verified or until no keys are left.
endpoint. All valid JWKs 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
Loading