0

We have an external website that is using Salesforce Identity to authenticate and authorize access to an API.

We have setup the Oauth2 flow using PKCE as per the following link. https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_web_server_flow.htm&type=5

This works fine except the access_token returned is not a JWT. As per the Oauth2 spec and the OpenId spec the Access_token should be a jwt: https://datatracker.ietf.org/doc/html/rfc9068 https://openid.net/specs/oauth-v2-jarm-final.html

Is there a way to get the access token as a JWT as per the specs?

identigral
  • 7,543
  • 29
  • 32
  • 42
CloudingAround
  • 50
  • 5
  • 1
    The "specs" are not universal law, vendors choose what they support. Salesforce does not implement JARM. If your use case is authorization of access to an API, why does the token format matter? You pass it to Authorization Service (SF) and it'll grant you access. – identigral Jan 30 '23 at 17:59
  • @identigral thanks for the info. The reason we care is that we are trying to work out how the API can validate the access token. If the access token is a JWT we can just validate like we do with any JWT. If it is not a JWT then we need to do another call to validate the access token via the Salesforce introspection endpoint. – CloudingAround Jan 30 '23 at 19:42
  • 1
    Ah, didn't carefully read your first sentence. Authorization via SF to your own API isn't going to work the way you want/think. Your best bet is to use OpenID Connect and id_token. You might be able to stuff custom claims in there. Access token comes back as JWT only in JWT Bearer flow. – identigral Jan 30 '23 at 19:50
  • Thanks, the id_token works great. The problem is there are some websites saying we should never use the id_token for accessing an API. For example: "One of the most common mistakes developers make with an ID token is using it to call an API." https://auth0.com/blog/id-token-access-token-what-is-the-difference/ – CloudingAround Jan 30 '23 at 19:57
  • 1
    In general, it's true that id_token should not be used for authorization. In your case if you must use SF for authorization, you don't have much choice. All you can rely on is the user's identity plus associated claims or object graph of assets you can pull out via more API calls back to SF. This is more or less a special case of token exchange minus the official protocol you were interested in your other question. Whether this is ok or not (and leads to security issues) depends on many variables in your solution architecture. – identigral Jan 30 '23 at 20:01
  • One alterative to using the id_token is to have the API call the userinfo endpoint using the access token. Then claims could be returned to the API from that endpoint. However, some websites are also saying the API should not access the UserInfo endpoint so not sure if this is an option or not. – CloudingAround Jan 31 '23 at 12:33
  • One thing I realise is both the UI (Client) and API (Resource Provider) both need the same info. They both need some user permission information such as the role. The UI will use this information to decide which info to render to the user. The API will use this info to decide what data to send to the ui etc. This user permission based info such as role are user specific and so dynamic in nature. From my limited understanding of Oauth2 it seems the spec doesn't provide any method for dynamic or grannular authorization information to control who has access to what. – CloudingAround Jan 31 '23 at 12:37

0 Answers0