Best Practice to validate Authorization token

We have api endpoints to generate session token using “/v0.5/sessions”. What is best practice to make sure that token is valid for the current duration?

Should we keep track of it using expiresIn property that we get or should be generate token each time we need access token (not a best practice i think) or is there any API through which we can validate the token?

Currently, we are not exposing any API to validate the token. Please keep track of expiresIn property.

create an async method that will call “/v0.5/sessions” this endpoint and fetch you a new token.

Call this method when any of the api endpoints is hit.
It will ensure that a new token is always generated before an API endpoint does a POST, ensuring security.
Also, you don’t have to worry about token expiry as a new token will generate before the POST Call.

It will also automate the process of passing a new token. @bhaskar.dabhi @Mounica

Please do not unnecessarily hit the /sessions API. It will be throttled as well in production. Fetch a token only when needed. In near future, you can also use “refreshToken” to get a new “accessToken”.

The “accessToken” that you receive is a JWT token. You can find out from the payload - typical “exp” attribute in UNIX epoch time is specified. You can also find out from the /sessions response.

And you can do verification of the token using the Gateway’s public cert which you can figure from https://dev.ndhm.gov.in/gateway/v0.5/certs

1 Like

Hi @angshuonline

Thanks and noted.
Can you provide link/url to refreshToken doc ? That would help to refactor the code.

Thanks

Hi @vineet_agrawal,

Please find below the curl to get access token using refresh token.

--header 'Content-Type: application/json' \
--data-raw '{
    "clientId": "<client_id>",
	"clientSecret": "<secret>",
    "grantType": "refresh_token",
    "refreshToken": "<token>"
}'

We will be updating the Sandbox document soon.

Thanks, @Mounica. Noted. Posting the complete curl text for everyone.

curl --location --request POST 'https://dev.ndhm.gov.in/gateway/v0.5/sessions '
--header 'Content-Type: application/json' \
--data-raw '{
    "clientId": "<client_id>",
	"clientSecret": "<secret>",
    "grantType": "refresh_token",
    "refreshToken": "<token>"
}'
1 Like

With reference to:

Currently, we are not exposing any API to validate the token. Please keep track of expiresIn property.

@Mounica

Does that mean that we are not supposed to validate the JWT present in Authorization header when we get an API call?

Hi @tuntunia,

You have to validate the token coming in Authorization header. You can use Gateway Certs to validate the JWT token.

Hi @dheerajp,

Thanks for the quick response. How do we come to know when these certs get updated/refreshed or are we supposed to fetch it each time?

@mdubey @dheerajp,

I agree with @tuntunia’s feedback. What is mechanism to validate that request is coming from NDHM only?

I am not sure how to use the certs given and also what if its changes suddenly.

Hi @tuntunia, @bhaskar.dabhi,

Right now this is the way to validate tokens which is being used across the services by us as well. The changing of certificate would always go through a process and it will not happen suddenly and there will be announcements regarding this.

However a few things you can do for ensuring the latest certificates.

  • On the restart of server, make sure you fetch the latest certificate.
  • Periodically fetch the certificates, probably once a day/week etc.

Thank you

Thanks @mdubey for the clarification. Will do fetch once or twice a day.

Hi @vineet_agrawal

Thank you for providing complete curl.
But while generating new token with refresh token, It also generates new refresh token.
Is it an expected behavior that refresh token will also be modified?

why i need to pass client credentials when i am refreshing token using refresh token. So the idea of using a refresh token is to prevent user from providing his credentials every time, right? I don’t feel its logical. Also is the expiry timeout for refresh token too short (6 min? Ideally refresh tokens do have greater time span, at least it could be 1 hour. But updating the refresh token after a refresh request seems logical for security purpose.

@navaneethpk thought of checking how you are using the access/refresh tokens. I am as well not sure why the api is designed in such a way that client id and client secret need to be passed when refreshing the tokens. This defeats the purpose of refresh token. I also noticed that old refresh tokens continue to work even after a new one is issued. Not sure if we need to request token every time before calling api or use the refresh token. Even the refresh token expiry is too short.