cerner access_token validation

[Shehraz Khan]

Hi, I am implementing an authorization from Cerner to my desktop application. 
The workflow is user clicks on a link and authorizes itself using its credentials.
And redirect to a URL where its auth_code is used for retrieving of access_token.
I successfully retrieved the access_token.

Now I want to retrieve data from Cerner, using this access token.
I am using the Spring rest template to call Cerner's data endpoints.

But problem is that I need to validate the token as after some time the access_token expires. 
So before every request to Cerner, I want to validate the access_token.

Is there is any way I can validate access_token?
I have gone through this post from google group.

https://groups.google.com/forum/#!searchin/cerner-fhir-developers/validate$20access$20token%7Csort:date/cerner-fhir-developers/ZJZHCi_FeoU/v1o13qoEBAAJ

it mentions to find /tokeninfo endpoint from 
 curl -i -H "Accept: application/json+fhir" https://fhir-open.sandboxcerner.com/dstu2/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/metadata

but in metadata there is no endpoint for /tokeninfo.

I am using fhir dstu2 specification and cerner sandbox for development.

Thanks,
Shehraz Khan

[Michele Mottini]

...request some data using the token, if it fails with 401 the token is no longer valid...catch that error, refresh the token and re-issue the data request

  - Michele

  CareEvolution Inc

[Jenni Syed (Cerner)]

The expiry time is in the token response from the authorization server. EG from http://fhir.cerner.com/authorization/#processing-the-authorization-grant-response:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: OPTIONS, POST
Access-Control-Allow-Headers: Content-Type, Authorization
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/json
Content-Length: 1462
Date: Tue, 01 Nov 2016 19:20:25 GMT

{
  "access_token": "eyJraWQiOiIyMDE2LTExLTAxVDE1OjExOjQ4LjY1NS5l...",
  "scope": "user/Observation.read",
  "token_type": "Bearer",
  "expires_in": 570
}

You should store the expires_in (calculated to the app local time, eg: current time you got token + expires_in) along with the token so you can get a token in advance of the expiry time. We don't recommend waiting until you get an error as that increases wait time for the end user.

Regards,

Jenni

[Shehraz Khan]

Actually below is the endpoint that I wanted. Thanks @Jenni Syed and @Michele Mottini for reply. 

[Jenni Syed (Cerner)]

Hi,

We don't recommend using the introspection endpoint to determine if the token has expired/needs to be refreshed from the app's perspective, since the information is returned as part of the token request (it's not very efficient to make an external call for this info when the app already has access to this without needing to introspect/process the token itself).

Regards,

Jenni