Closed wmathurin closed 1 week ago
NB: I decided not to change the transparent refresh logic. I'm not sure that the added complexity of preemptively refreshing before sending a request if using an expired JWT-based access is worth doing. Thoughts?
1 Warning | |
---|---|
:warning: | No Lint Results. |
Generated by :no_entry_sign: Danger
1 Warning | |
---|---|
:warning: | No Lint Results. |
Generated by :no_entry_sign: Danger
1 Warning | |
---|---|
:warning: | No Lint Results. |
Generated by :no_entry_sign: Danger
1 Warning | |
---|---|
:warning: | No Lint Results. |
Generated by :no_entry_sign: Danger
Overview
Connected app / external client app can be configured to issue JWT-based access token (for more information see here).
The mobile application does not need to know if it is using a JWT-based access token or an opaque token in most cases. Login and refresh will just work as before.
However, front door URL cannot be built directly using the JWT-based access token. Instead the single access API should be called to generate front door URL.
We already made changes in the Mobile SDK to be JWT-based access token ready:
Changes in this PR
JwtAccessToken
to allow apps to inspect the JWT encoded in the JWT-based access token.SalesforceWebViewCookieManager
i.e. the class responsible for hydrating the web view sessions in hybrid remote apps when JWT-based access token are in use.Testing
JwtAccessToken
.