jb7fc (jb7fc) asked a question.
Hi there,
I am developing a browser extension that requires authenticated users, and am not entirely sure what flow I should be aiming for.
The browser extension needs to communicate securely with a Java Spring based REST API. Given that the browser extension is client-side, it would not be good to use a flow that requires the client secret. I've successfully implemented the Auth Code with PKCE flow, and this provides the extension with access and id tokens. The access tokens work fine for accessing the REST API. So far so good.
The problems come up due to the short lifecycle of these tokens, which are only valid for an hour. The expected user experience for browser extensions is that they would be set and forget, that you would very rarely have to re-authenticate. I need to refresh the tokens behind the scenes, ideally even after the user restarts the browser. Unfortunately the PKCE flow doesn't allow me to get a refresh token, so I don't see any way of doing this.
Can anyone help me out? Just looking for a high-level picture of what flow I should be aiming for. Some options that I have thought about but don't know if they are a good idea:
1) Is there a way to make repeat invocations of the PKCE flow silent, so the browser could get new tokens without showing the Okta login screen? What are the limitations here, in terms of how often the user would/would not have to re-enter login details?
2) Is there a secure way to have my REST API obtain the refresh token and pass it along to the extension?
3) Is there a secure way to have my REST API refresh the id and access tokens, and pass them along to the extension?
Thanks in advance,
Dave
In case other people stumble across this with similar questions, I've believe I have found an answer:
The Auth Code with PKCE flow does provide refresh tokens, you just have to include the offline_access scope in your requests for auth code. Not sure how I missed this =/
The next stumbling block was that the instructions for refreshing tokens implies you need a client secret since the only example includes an auth header. This seems to have led others to believe the token refresh has to occur server side. However, this is not the case, you can happily use a refresh token without requiring the client secret. Here is a request that worked for me:
http --form POST https://${yourOktaDomain}/oauth2/default/v1/token \
accept:application/json \
cache-control:no-cache \
content-type:application/x-www-form-urlencoded \
grant_type=refresh_token \
redirect_uri=${redirectUri} \
scope=offline_access%20openid \
refresh_token=${refreshToken} \
client_id=${client_id}
This combined with refresh token rotation seems to be a pretty ideal setup. The browser extension does not need the client secret. Each refresh token can only be used once, and they are valid for seven days by default. So, users will only need to re-enter login details if they are inactive for seven days, which seems reasonable.