Securing Applications and Services Guide
Fleeting- External reference: https://www.keycloak.org/docs/latest/securing_apps/#validating-access-tokens
- External reference: https://www.keycloak.org/docs/latest/securing_apps/
- see,
While OAuth 2.0 is only a framework for building authorization protocols and is mainly incomplete, OIDC is a full-fledged authentication and authorization protocol
OIDC also makes heavy use of the Json Web Token (JWT) set of standards
These standards define an identity token JSON format and ways to digitally sign and encrypt that data in a compact and web-friendly way
two types of use cases when using OIDC
[…]
The first is an application that asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an identity token and an access token
[…]
The identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
[…]
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an access token it can use to invoke on other remote services on behalf of the user. Keycloak authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token, verifies the signature of the token, then decides based on access information within the token whether or not to process the request.
OIDC was designed to work with the web while SAML was retrofitted to work on top of the web
As tokens are in the JSON format, they are easier to consume by JavaScript
Validating access tokens
If you need to manually validate access tokens issued by Keycloak you can invoke the Introspection Endpoint. The downside to this approach is that you have to make a network invocation to the Keycloak server. This can be slow and possibly overload the server if you have too many validation requests going on at the same time. Keycloak issued access tokens are JSON Web Tokens (JWT) digitally signed and encoded using 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 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.
— https://www.keycloak.org/docs/latest/securing_apps/#validating-access-tokens