On mobile apps common practice was: Usage of one hardcoded client_id and secret for all app installations on any device. By design this kind of client cannot be confidential. Mobile apps can be decompiled. Although there are some techniques to hide the secret and make it harder to reconstruct it — the secret is never really safe.
App A is developed by trusted source. It's redirect uri may be something like:
my-own-app://back-from-oauthIt implements the standard authorization code grant. It registers to
App B is developed by some harmful Hacker who decompiled App A and received client_id and secret. It registers to my-own-app://back-from-oauth, too. Somehow this Hacker gets a user of App A to install App B, too. When the user now starts App A and has to login again - after the redirect App B opens (current Android Versions now ask which app has to be opened - not so for iOS and old Android versions still on the market), gets the authorization code and can do a token request to make a valid access token out of it.
PKCE modifies the standard authorization code grant. Before starting the authorization code grant, a random string called
code_verifieris generated using the characters: [A-Z], [a-z], [0-9], "-", ".", "_" and "~", with a minimum length of 43 characters and a maximum length of 128 characters. Additionally to the
code_challengeis created. Doorkeeper supports two code_challenge_methods to generate the
code_challengeis the same as the
code_challengeis the SHA256 Hash value of the
code_verifierurl safe base64 encoded (without trailing "=" compare to: https://tools.ietf.org/html/rfc7636#appendix-A)
Now when the mobile app redirects into the browser to https:///oauth/authorize, add two parameters. Next to
state, you add now
code_challenge_method. Remember: doorkeeper supports the two methods "plain" and "S256". We do not recommend to use plain.
When your app opens after the redirect to the redirect_uri and the app got the
authorization_code, add another parameter to your token request. Next to
grant_type, you add the
code_verifierto your /oauth/token POST request. Doorkeeper will now use the already known
code_challenge_methodto create its own
code_verifier— and compare it to the already stored
/oauth/authorizerequest. If they do not match, you get an error message to have done an
If now App B receives the authentication code, it cannot request a token for it, since it cannot know the nonce that was created only for this one request.
bundle exec rails generate doorkeeper:pkce
This step is optional and you will be able to add this later if necessary.
If you overrode the
doorkeeper/authorizations/new.html.erbview, make sure that you have the
code_challenge_methodhidden form fields.
Also, in case your client is public (e.g. mobile app, single page app) note that the
Doorkeeper::Applicationfor the client should have
confidential: false. Otherwise Doorkeeper will try to authenticate the client using the client_secret, which the client, being public, shouldn't know about.
Discussion over PKCE flow and refresh tokens you can find here: https://github.com/doorkeeper-gem/doorkeeper/issues/1285