4

I'm new to salesforce and I'm trying to obtain a access token with password grant,

I can successfully obtain the access token:

Request:

    POST /services/oauth2/token HTTP/1.1
    Host: .....my.salesforce.com
    Content-Type: application/x-www-form-urlencoded
    grant_type=password
&client_id=MY_CLIENT_ID
&client_secret=MY_CLIENT_SECRET
&username=some_email
&password=some_password

Response

{
    "access_token": "some_token",
    "instance_url": "https://......my.salesforce.com",
    "id": "https://test.salesforce.com/id/00D260000001G7lEAE/00526000004wk0wAAA",
    "token_type": "Bearer",
    "issued_at": "1589009375588",
    "signature": "Q9Au4839PUdEfCamO7Qvjereo9i+kjimpbR3tfVAeVw="
}

However when I introspect the access token

            POST /services/oauth2/introspect HTTP/1.1
            Host: ......my.salesforce.com
            Content-Type: application/x-www-form-urlencoded
            token=some_token
&token_type_hint=access_token
&client_id=MY_CLIENT_ID
&client_secret=MY_CLIENT_SECRET

Introspection response

{
    "active": false
}

Why the token is not active?

3
  • I'm not really set up to test this out myself right now, but perhaps it's just an indicator that the token hasn't been used yet. I'd be curious to see whether you can make a request with that token (well, actually I'd suggest going into SFDC, invalidating that token, and getting a new one since it's now on the internet at large) and if that "active" status changes after you do so.
    – Derek F
    May 9 '20 at 11:36
  • It could also be that Salesforce isn't using that parameter for anything, but specifies a safe default to comply with the relevant RFC that states that "active" must be present in the response.
    – Derek F
    May 9 '20 at 11:40
  • Good point about token, this is our test env not production. I made a get request to https://dpos--newsit.my.salesforce.com/services/oauth2/userinfo with token as bearer and it succeed. However introspection endpoint only and only returns { active : false }, which I don't understand. I want to see token exp time there. Please keep in mind I'm new to SF. Thanks for your time.
    – Lucy
    May 9 '20 at 17:01
5

The response of {"active": false} is only allowed in very specific context. From oAuth Introspection spec (RFC 7662):

If the introspection call is properly authorized but the token is not active, does not exist on this server, or the protected resource is not allowed to introspect this particular token, then the authorization server MUST return an introspection response with the "active" field set to "false".

Even though one can't verify with certainty from merely reading your question, in your case it appears that the call is properly authorized, the token is active, it does exist on this server. That leaves the possibility of protected resource not being allowed to introspect this particular token. Indeed, the introspection privilege is the root cause of this issue.

In your connected app, if you select Introspect All Tokens, you'll see a valid response:

{
"active": true,
"scope": null,
"client_id": null,
"username": "foo@bar.com",
"sub": "https://test.salesforce.com/id/00D../005..",
"token_type": "sid",
"session_type": "Oauth2",
"exp": ...,
"iat": ...,
"nbf": ...
}

SF doc does say that "By default, all connected apps can introspect their own tokens" and (presumably) this token was issued by this connected app. If the token was issued by the connected app in an org different from one that was doing the introspection, the requirement to grant introspection privileges by checking this option on the connected app would have been a fair ask. With the token being issued by the same app in the same org, the need to select Introspect All Tokens is either a documentation and/or implementation bug.

3

Haven't found any documentation to support this, so it's just speculation, but based on the lack of any mention of an "active" parameter (outside of child sessions) in the documentation on token introspection, and the OAuth token introspection RFC's statement that the "active" parameter is required, I'd say that Salesforce is just setting a default value (false) to be compliant with the RFC.

Based on your comments, your primary concern here is seeing when the token expires (perhaps to know whether or not you need to get a new token).

Token expiration isn't that straightforward. Not super complicated, it's just not a simple time value that can be given.

  • From my experience, an OAuth token causes a new and independent session to be created
  • Session timeout can be specified by the connected app (which is something you need to set up to be able to authenticate via OAuth) for anything ranging from 15 minutes to 24 hours (I think 24 hours is the upper limit)
  • If not specified by the connected app, sessions started under that connected app default to the organization session timeout setting (type "Session Settings" in the quick type box in your org's setup area to see/edit your org session timeout)
  • Provided the token is still valid at the time you use it to make a request, I believe any request will cause the session timeout to be reset

I have an integration into my org that makes an API call every 2 minutes (unless the system sending the requests runs into issues like running out of RAM). That resets the session timeout, so the same token has been in use since the last time I needed to update the certificate used by the connected app (about 6 months ago).

So how do I know if the token is expired?

I think the general approach is to not be overly concerned about that happening.

If the token is no longer valid, you'll get an HTTP 403 (or some 4xx error) back from your request. You can just add some logic to identify that scenario, and then start at the beginning of your OAuth 2.0 flow again to get a new token (so that you can then retry the request you wanted to make in the first place).

1
  • You say, "Token expiration isn't that straightforward. Not super complicated, it's just not a simple time value that can be given." But it should be straightforward. Introspecting will return the exp value, exactly what's desired to determine life expectancy of the token. Coding for a 403 error shouldn't be the standard procedure when a proactive step can prevent a fail scenario.
    – Tony
    Aug 24 at 2:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.