KEYCLOAK-5287
This commit is contained in:
parent
a4937d2c67
commit
004d7c750b
1 changed files with 14 additions and 2 deletions
|
@ -55,6 +55,7 @@ The user agent can be redirected to the endpoint, in which case the active user
|
|||
|
||||
The endpoint can also be invoked directly by the application. To invoke this endpoint directly the refresh token needs to be included as well as the credentials required to authenticate the client.
|
||||
|
||||
[[_certificate_endpoint]]
|
||||
===== Certificate Endpoint
|
||||
....
|
||||
/realms/{realm-name}/protocol/openid-connect/certs
|
||||
|
@ -62,14 +63,16 @@ The endpoint can also be invoked directly by the application. To invoke this end
|
|||
|
||||
The certificate endpoint returns the public keys enabled by the realm, encoded as a JSON Web Key (JWK). Depending on the realm settings there can be one or more keys enabled for verifying tokens. For more information see the link:{adminguide_link}[{adminguide_name}] and the https://tools.ietf.org/html/rfc7517[JSON Web Key specification].
|
||||
|
||||
[[_token_introspection_endpoint]]
|
||||
===== Introspection Endpoint
|
||||
....
|
||||
/realms/{realm-name}/protocol/openid-connect/token/introspect
|
||||
....
|
||||
|
||||
The introspection endpoint is used to retrieve the active state of a token. It can only be invoked by confidential clients.
|
||||
The introspection endpoint is used to retrieve the active state of a token. In other words, you can use it to validate an access or refresh token.
|
||||
It can only be invoked by confidential clients.
|
||||
|
||||
For more details see https://tools.ietf.org/html/rfc7662[OAuth 2.0 Token Introspection specification].
|
||||
For more details on how to invoke on this endpoint, see https://tools.ietf.org/html/rfc7662[OAuth 2.0 Token Introspection specification].
|
||||
|
||||
===== Dynamic Client Registration Endpoint
|
||||
....
|
||||
|
@ -81,6 +84,15 @@ The dynamic client registration endpoint is used to dynamically register clients
|
|||
For more details see the <<_client_registration,Client Registration chapter>> and the
|
||||
https://openid.net/specs/openid-connect-registration-1_0.html[OpenID Connect Dynamic Client Registration specification].
|
||||
|
||||
==== Validating Access Tokens
|
||||
|
||||
If you need to manually validate access tokens issued by {project_name} you can invoke the <<_token_introspection_endpoint,Introspection Endpoint>>.
|
||||
The downside to this approach is that you have to make a network invocation to the {project_name} server. This can be slow and possibily overload the
|
||||
server if you have too many validation requests going on at the same time. {project_name} issued access tokens are https://tools.ietf.org/html/rfc7519[JSON Web Tokens (JWT)] digitally signed and encoded using https://www.rfc-editor.org/rfc/rfc7515.txt[JSON Web Signature (JWS)].
|
||||
Because they are encoded in this way, this allows you to locally validate access tokens using the public key of the issuing realm. You can either hard code the
|
||||
realm's public key in your validation code, or lookup and cache the public key using the <<_certificate_endpoint, certificate endpoint>> with the Key ID (KID) embedded within the
|
||||
JWS. Depending what language you code in, there are a multitude of third party libraries out there that can help you with JWS validation.
|
||||
|
||||
|
||||
==== Flows
|
||||
|
||||
|
|
Loading…
Reference in a new issue