Type in your question below and we'll check to see what answers we can find...
Loading article...
Submitting...
If you couldn't find any answers in the previous step then we need to post your question in the community and wait for someone to respond. You'll be notified when that happens.
Simply add some detail to your question and refine the title if needed, choose the relevant category, then post.
Before we can post your question we need you to quickly make an account (or sign in if you already have one).
Don't worry - it's quick and painless! Just click below, and once you're logged in we'll bring you right back here and post your question. We'll remember what you've already typed in so you won't have to do it again.
Please see below the most popular frequently asked questions.
Loading article...
Loading faqs...
Please see below the current ongoing issues which are under investigation.
Loading issue...
Loading ongoing issues...
Hi,
OAuth2 specifications list PKCE as an extension to the standard. As you state in your documentation, the refresh token can only be used once. Why is this? I could not find such a recommendation, although the original spec did state that old refresh tokens may be revoked after a new one is issued. So why PKCE specifically, added security?
Granted, refresh tokens can be chained, and the tokens can be used for the full duration, even after consuming the refresh token. But having a single refresh token from which to spawn new tokens is quite practical. For my specific use case: performing automated tests against the Web API with e.g. Travis was possible thanks to generating a user token from the same refresh token over and over again. As PKCE was meant to be an improvement and replacement to the vanilla user authorisation, I'd like to see it being used exclusively, but this refreshing complicates things.
So, are you set on these semantics for PKCE? If so, are you planning on making the case for vanilla user authorisation stricter as well?
Many thanks,
Felix Hildén
Solved! Go to Solution.