-1

I have Authorization Server and Resource Server as two different entities. I am calling REST API with the Access Token in header. I want to check the validity of the AT, whether it is active or not?

I have done some googling and found that we can validate the access token using token introspection end point, which requires ClientID and clientsecret as well. But in the rest API I'm not passing those(i.e clientID and clientsecret) information.

ankit
  • 25
  • 1
  • 2
  • 11
  • Definitely you shouldn't validate the token by yourself, you MUST call the IDP that provided the token and ask it if the token is valid. – Zorglube Feb 21 '23 at 17:33
  • @Zorglube In the API we are not passing the client id and client secret. And the IDP is expecting those information to validate the token. – ankit Feb 21 '23 at 17:49

2 Answers2

1

The answer will depend on the format of the access token. If it is a JWT, which is the preferred option, use code similar to this:

@Configuration
public class SecurityConfiguration {
    
    @Bean
    public SecurityFilterChain filterChain(final HttpSecurity http) throws Exception {

        http
            .antMatcher("/api/**")
            .authorizeRequests(authz -> authz
                .anyRequest().authenticated())
            .oauth2ResourceServer().jwt();

        return http.build();
    }
}

Along with configuration similar to this:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          jwk-set-uri: https://login.example.com/.well-known/jwks.json

INTROSPECTION

If your API receives a reference token, eg in a UUID format, then introspection will instead be required.

Spring has a similar option to implement this, though it is more commonly done in an API gateway hosted in front of the API, rather than in the API's own code.

Introspection is usually accompanied by caching of the introspection result, to avoid hammering the authorization server, which is usually a critical component.

Gary Archer
  • 22,534
  • 2
  • 12
  • 24
0

First, It's better to understand the authentication types, IDP, token types and grant types, API gateways to get a clear understanding of the high-level authentication flow.

There are different types of grant types in the OAuth framework[1].

Client credential grant type[2] is one of the grant types.

If you need to follow a standard authentication mechanism, it's better to use an Identity provider to generate tokens and validate them. (You can implement it on your own, but it is easy to use already implemented one)

There are different types of token types.

  1. JWT[3] - These are Self Contained tokens. It is ideal to use JWT access tokens as API credentials because JWT access tokens can carry claims (data) that are used in order to authenticate and authorize requests. No need an introspection endpoint for this since the token itself has informations to validate the token

  2. Opaque access tokens[4] - An opaque or a reference token is a random and a unique string of characters which has been issued by the token service as an identifier to be used for API authentication purposes. These tokens does not carry any information related to user, hence it is required to open a back channel to the token validation service to validate it and retrieve token information. For this it needs an introspection endpoint

To secure your APIs, it will be easy to use an already-developed API gateway(There are plenty of API gateways[5]). Integrating an API gateway to your APIs will provide the capability to add security for your APIs. From this you don't need to worry about implementing authentication for your APIs.

[1] https://is.docs.wso2.com/en/6.0.0/references/concepts/authorization/grant-types/

[2] https://is.docs.wso2.com/en/6.0.0/references/concepts/authorization/client-credential-grant/

[3] https://apim.docs.wso2.com/en/latest/design/api-security/oauth2/access-token-types/jwt-tokens/

[4] https://apim.docs.wso2.com/en/3.1.0/learn/api-security/oauth2/access-token-types/opaque-tokens/

[5] https://apim.docs.wso2.com/en/latest/get-started/overview/

chashikajw
  • 592
  • 5
  • 18
  • I have basic understanding of authentication types & granttypes. I am having the second type of token i.e opaque access token. And to validate it I have to call the token introspection end point, which requires client id and client secret as well. And in the api the api consumer is only passing the access token in Authorization header not clientid and client secret. – ankit Feb 23 '23 at 05:11
  • Yes. API consumer is not passing the client id and client secret to the API. The token is generated from the IDP using the client id and client secret. The opaque token has just a reference id for the token. To validate an opaque token, the recipient of the token needs to call the IDP that issued the token. That's the normal behavior. – chashikajw Feb 23 '23 at 05:43