very good explanation, thank you! the only further potential attack would be if the malicious app could somehow gain access to the myapp memory to leak the code_verifier, but in this case nothing else would be secure on this operating system anymore ^^
I understand that Hacker App can not use the stolen Auth Code to get Access Token because of PKCE but - why can't Hacker app use the clientID of your app and generate a code verifier then ask Authorization Server for a Auth Code and then again for Access Code?
Hello Arbaaz! That is a good question and the answer is that this scenario is not the concern of PKCE. If someone would 'copy' an app and register the same redirect_uri, that could happen. However, PKCE can only prevent one app from using another app authorization_code. I hope this helps
Doesn't the authorization server check the client_secret before issuing the access token ? Client B cannot exchange the auth code for an access token because it doesn't have the required client_secret. Am I missing something here ?
Hello Aditya! That is a good question. Please note that PKCE is meant for public clients. Public clients do not have a client_secret. You may see implementations that carry one but that is practically useless. If you think of javascript, the client_secret is visible in the code in the browser and with that it is not a secret. I have created a video about client types, maybe that is of interest for you also. I hope this helps, and thanks for the question!
Very nice video, explained it very good! Thanks a lot, you saved my ass a little bit. I'm about to hold a OAuth 2.0 Presentation tomorrow and I always wondered how a "dynamic client secret code" is realized. 10/10
@@Idnt_know Hello! Although my name is Russian, I am German and could help you either in German or English. Can you submit your comment again please, unless it is not meant or me. Thank you
Ok, so I put your comment into translate.google.com and it seem the video was helpful for you. Very good! In regards to examples, have you got a specific use case in mind?
Hey! Great explaination thanks. I have a doubt about something you replied in one of the comments about code_verifier i.e "The POST is sent via SSL between the client and the authorization server, no browser involved. My doubts: 1.) If code_verifier is exposed to hacker, then PKCE doesn't ensure any security, right? 2.) If the implementation use Single Page Application (SPA) and it is responsible for all the authentication/authorization. In this case the interaction can only happen through browser, and the hacker can get access to code_verifier. So does PKCE ensure any security in that case?
Hello Pramod! Thank you for the question and thanks for looking into earlier comments. You are right, if the code_verifier gets into the hand of a hacker app PKCE has lost, so to say. But the chances are small and ideally it is a one-time only value meaning the same value can only be used per authorization step. For your second question, I should have said there is no 'browser redirect' involved. Because, as you say, a SPA is running in a browser and therefore the browser is involved. But the main message should have been that the client (JS script client in this case) is connecting to the authorization server directly, via SSL/TLS without exposing any connection details to the browser URL. I hope that clarifies it and I hope that it is what you were expecting.
What if the hacker app doesn't get the authorization code, both authorization code and code verifier are sent to IDP, and the token is sent back but now what if the hacker app gets the token? Is this prevented in any way?
Hello Mustafa! Please keep in mind that the code and verifier are exchanged via SSL directly between the app and the server. The token ends up in the context of the app which lives in its own sandbox. If another app would be able to access any of its data the whole app ecosystem would be compromised. Therefore, the scenario of a stolen access_token in this scenario is unlikely to happen. However, to answer your question for the general case, as long as the token was issued as a bearer token it can be used by any app that it is possession of it! On that note, if you have the time, watch my video about implicit flows that touches on that topic also. I hope this helps!
Hi Mac! No, that is not possible. The authorization_code is returned via a redirect_uri where as the access_token it exchanged via TLS, directly between the app and the auth server. I hope this helps.
Hello! Imagine it like this (not completely accurate, but good for understanding the difference): - the authorization_code is delivered to the app like a letter to an apartment building. Imagine a high-rise with 100 apartments but two of those have the same apartment numbers. The letter will end up in one of those two letter boxes. Just like the OS which selects one app having the same redirect_uri. - The token exchange is more like a phone call between two parties. I hope this helps!
Wonderfully explained... If a guy can't understand the concept here.. he'd not be able understand anywhere for sure. Looking forward to see some long good video on "Proof-of-Possession" please..😊
Thanks for the video. It explains in a clear and visual way the value of PKCE. I have one question. Why do you use semicolons instead of dots in the domain, i.e. me:myapp:one:com instead of my.myapp.one.com? Disclaimer: I have little experience with mobile development.
Hello Peter, no problem! If you search for custom schemes you will find that this pattern of using colons (:) for domain names is very typical. Other examples are: myscheme://path.to.my.app. The main point is to find a unique value so that your URL does not clash with others. I hope this helps.
Hi Sascha, thanks for the great video:) So did I get this right? Use case for this is using the authorization code flow for systems with public clients that don't have a backend service. Let's say, a calendar app that combines your google, microsoft and apple calendar into one. You wouldn't need a custom backend for that, just the app. I have 3 questions: Is auth_code + pkce more or less the replacement for the implicit flow? With a custom backend you wouldn't need pkce as it has a secret which the auth server knows and uses to validate the token-request instead of the code_verifier, right? How does pkce help with the calendar app in a browser? An extension could maybe still get the code_verifier, as it has access to a web page's internal javascript.
Hi Boiii! Her are your answer: - Is auth_code + pkce more or less the replacement for the implicit flow? No, it is complimentary - With a custom backend you wouldn't need pkce as it has a secret which the auth server knows and uses to validate the token-request instead of the code_verifier, right? Yes, however, it is recommended to use PKCE in any scenario with authorization_code flows - How does pkce help with the calendar app in a browser? An extension could maybe still get the code_verifier, as it has access to a web page's internal javascript: They run on different domains, right? You need to find a secure location for your code_verifier. Local Storage is probably your obvious choice. Please find more info on best practice for auth apps in browser I hope this helps!
Hi Alexis! No, you could not get or extract the code_verifier based on the code_challenge and code_challenge_method (unless the method is PLAIN). The code_verifier is only exchanged via SSL directly with the authorization server. I hope this helps.
I realize this is an old video but if you're still paying attention to comments, I am a little confused about the code verifier. Does the server know the verifier beforehand? What keeps the hacker app from sending it's own verifier code,?
Hi Matt! The verifier is generated by the client, on the fly, per authorization request. The hacker would have to be able to derive the verifier from the sha-256 hash of it. The chances are basically 0 to achieve that. For example: this is the base64 encoded hash of a short string and the chances of you figuring out what the sentence is ... probably not going to happen: yWIgwAZPNpBFshwG7lIU2KTFntFQKQ+LRebfFZrBiDQ=. This means, whatever verifier the hacker app sends, the server will use it to regenerated the sha-256 hash of it and it will not match the value that was given to the server in the beginning of the authorization flow. I hope this helps!
Freejack1982, no, PKCE is not used when refreshing token. It is only specified for the initial authorization code request. Since you client communicates with the authorization server via SSL directly, the new token are part of the response. There is not party in between you and the authorization server.
Thanks for explanation, although I don't see any value in PKCE especially in authorization code flow since when you are exchanging authorization code for token you use secret key for that which is stored server side only and assure secure exchange...
Hello Eddy, thanks for your thoughts! Unfortunately, for all public clients, such as mobile apps, java script apps, there is no client secret. Your described use case is only valid for confidential clients, such as web apps. I hope this clarifies it more. If not, please come back!
@@saschazegerman Well, this is why they use implicit flow and not the auth. code flow while by definition auth. code flow must be using secret key. But again, not going to argue my point :) Thanks again for investing time in the presentation and taking time to respond
Eddy, the implicit flow returns the access_token directly to the client, attached to the redirect_uri. This means the 'hacker' app would, instead of receiving 'just' the code, would get the access_token which is even worse! Please note that the implicit flow is not supported in the upcoming OAuth 2.1 spec. It is a very risky flow and should be avoided, especially for public apps. The use of the authorization_code should be used instead. In regards to the authorization_code flow, that can be used with public clients (no client_secret) and confidential client (with client_secret). I also made a video about client_types which may also clarify this topic. Thanks!
@@saschazegerman I know, and completely agree with you. What I meant was that by definition auth. code flow should be used with secret key and if application rely on client side only that it should use implicit flow and then PKCE makes more sense.
Eddy, the current suggestion by the oauth and openid connect working groups is to avoid using the implicit flow! Wherever possible the code flow with PKCE should be used. Here is a good summary: oauth.net/2.1/ Please note that RFC 6749 is not supporting your argument that the code flow should be used with client secrets. Please review paragraph 4.1.3. here: tools.ietf.org/html/rfc6749#section-4.1.3 In addition, PKCE is not defined for implicit flows as I mentioned in my video. Best regards!
Nice explanation! Two questions: 1. You mention that hacker app may intercept code_verifier in GET request. What is the mechanism for such interception? Or even not by hacker app, any third party. 2. In POST request that exchanges auth code for access token you have redirect uri. Is it just a typo?
Hello Saggit, thanks for watching the video! The authorization_code may be intercepted by any app that has registered the same redirect_uri (custom_uri) as your own app. The OS will launch one of them, either without notice or by asking the user which one to choose. For the second question, the redirect_uri is required in the code exchange request (/token) if the initial authorization_code request (/authorize) included included it also. I hope this helps!
@@saschazegerman Thanks for your reply! Regarding the first question. On the 5:40 mark you say this, referring to code_challenge URL parameter passed in GET request: "the hacker's app may also notice this value, but this doesn't add value to the hacker app, because it is a public value anyway". My question is, why URL parameter in GET request is a public value? What is the mechanism for its interception? Regarding the second question: all clear now, thank you!
@@saggitt If you look at the URL in a browser, you can see the full string which may include a query parameter. If you read this message, have a look at the URL, it may include ?v=... where v is a parameter. The point I was trying to make is that code_challenge is a value that may be seen by users or programs but has no value to anyone. Therefore, it is safe to include it in the URL. The code_verifier, however, cannot be shared in such a way since it should be a secret between your client and the server. Does this answer your question?
@@saschazegerman Thank you! I just forgot that this GET request is actually done by a browser, not by the app itself. So, for example, a browser extension would be able to read the url. Thanks again!
On 5:48 you mentioned than code_chalenge can be know by hacker app so why can't he use the same code-chaallege on GET method to get code-verifier. why will he generate random one. Can you please answer this question.
Hello Somappa, thanks for your question! The code_challenge is the result of sha256(code_verifier). The hacker app would need to be able to reverse that operation, something like 'code_verifier=reverseSha256(code_challenge)'. That is not possible. So, although a hacker app could reuse the same code challenge, that app would not be able to exchange the authorization_code for an access_token because it would not be able to provide the code_verifier. I hope this helps, if not, please come back!
Hi Sascha, this is an awesome walk through. Certainly one of the clearest online (I've been working through a couple today). One thing that isn't clear to me, how does the public client prevent the hacker app from getting the code_verifier, code_challenge, and code_challenge_method (either over the network or on the device)? I thought the challenge was that the hacker app can see traffic on the network and the device storage is not secure.
Hi Jesse! Thanks for watching my video! The code_challenge and code_challenge_method are public values, anyone can see them. The code_verifier, however, is the secret between the client and the server. But that is exchanged via the client and the server through TLS and therefore hidden from others. You would need a routed device in order to somehow encrypt those messages. The main problem that PKCE is preventing is the mis-usage of an authorization_code. I hope this helps!
@@saschazegerman Hi Sascha. But isn't the code from the server transferred to the client to TLS too? Maybe I did not understand the "custom url scheme" thing properly...
@@saschahoppe4833 Yes, but the recipient is the OS, so to say which then forwards it to one of the apps that registered the given custom URL. Does this clarify it?
@@saschazegerman Assume the hacker app gets access_code, what's preventing the hacker app to generate new pair of challenge & it's hash and send that instead to get access token?
@@akshaybhor6330 Thanks for your question. That authorization_code is already bound to the code_challenge which the authorization server remembers. If that authorization_code is exchanged for an access_token, the hack has to use its own code_verifier and that won't match the one that was used to generate the original value. I hope this helps!
Hello Ibiza! The code_challenge is a public value and with that any entity may see or use it. However, in the second part of the flow the client has to provide the matching code_verifier which lets the authorization server regenerate the code_challenge. And that is practically impossible. I hope this helps!
@@saschazegerman Thank you for explaining it in a better way. But if code_challange can be intercepted(Assuming by intercepting the Get request or may be by other way ), so in the same way code_verifier cane intercepted? I really can't understand why code_verifier can't be intercepted?
Hello Dheeraj, to abstract this a little more, here is a comparison with public mail. Imagine the code_challenge is sent via post card, everyone can read it. And the post card includes the code_challenge and the hashing method. Afterwards the code_verifier is sent with a letter, inside a sealed envelope. Only the recipient can read the content. Now, in order for someone to 'fake' being the sender, this someone would have to guess the code_verifier value that was inside the envelope. This analogy is not 100% true, but the idea behind it is. The post card is the URL in the browser and the envelope represents the encrypted TLS channel used to send the code_verifier. Please let me know if that helps!
Thank you for the great explanation. I do have one question. Wouldn't the hacker app able to intercept the {code_verifier} in the POST method in video playback@ 6:42?
Hello Rabbit Lee! The POST is sent via SSL between the client and the authorization server, no browser involved. That connection is encrypted and therefore the code_Verifier cannot be spoofed or intercepted. This, of course, is only true for devices that have not been rooted (jailbreak). I hope this helps!
Okay but what if the returned access token is then taken by the hacker app? or must the identifier be part of every api request to the resource server?
Hello Daniel! The access_token is exchanged via a TLS connection between the client and the authorization server and includes the code_verifier. A hacker app is not able to get in-between that connection. The code_verifier is not used again. I hope this helps!
Good video, however, I don't believe you explained how S256 and a random string that was generated and also available to both the hacker and the authorization server, in this case, how would the authorization server would be able to process the code verifier any differently when it is sent from the legit app or a hacker app, I wish you would elaborate a bit more on that.
Hi Moses, thanks for your interest in my videos. The random string is not available to the hackers app, only the hash of it. The hackers app would have to "guess" or "steal" the code_verifier in order to send it to the authorization server. The auth_server will use it to regenerate the hash value and compares it to the one given by your app. The hacker app will not be able to provide that code_verifier. I hope this helps, if not, please come back.
Hello Fikri! Thanks for watching the video and your question. If you have a server side application you can store the code_verifier as part of the current session. If it is a javascript (SPA) based app you may use the browsers local storage. This is the reference to my open source project 'Loginbuddy' where I have implemented a very simple SPA: github.com/SaschaZeGerman/loginbuddy/blob/master/net.loginbuddy.democlient/web/script/spa-demo.js You can see it in action here: client.loginbuddy.net In any case, it should give you an idea how it works. If not, please let me know.
@@saschazegerman thanks for your answer, i have two question again 1. pkce was created because authorization code is vulnerable to being stolen when the code is sent from server to app. if so, how can i secure the access token when sent by the server to app? 2. if i make a mobile app, where can i store the access token in mobile app?
@@fikrikamal7947 the access_token is exchanged via TLS, directly between your app and the server. That is a secure, private channel. After receiving the access_token you can either keep in memory until the app closes. In that case, your app needs to request a new one each time the app is opened. Another option is to use a public key to encrypt it, and then store it on the phone. When needing it, use the private key to decrypt it. I hope that helps.
@@DallasCowboyFan95 Hi there! I am not quite sure if I get the question. The authorization_code is exchanged via TLS, directly between the app and the authorization server. Can you explain a little more, please?
Great Explaination!! Sascha, I am using msal-angular and msal-browser packages for implement SSO login which uses OAuth 2.0 - PKCE. So achieved it. But I don't have any idea about refresh token how to handle. so can you make video on it or give some suggestion how to implement it in angular app.
Hi Daniel! Thanks for your question. Do you mean the server should encrypt the authorization_code using the clients public key? For that to work the client would have to generate a key pair at runtime and include the public key in its initial authorization request. Even though that might work, it is most likely more complicated and requires some more developer skills than generating a string-based verifier. The client should preferably also use POST instead of GET when creating the authorization request. However, technically it would work fine I believe. I hope this helps and let me know if you have other thoughts around this.
Well, the main idea of PKCE is to prevent appB from using an authorization_code issued for appA. PKCE cannot prevent an app to "steal" your client_id and "impersonate" your app. This means you could still technically "clone" a different app. Therefore, building a public client, which runs on mobile devices, requires very good naming, branding, well chosen redirect_uri(s) (custom uri), authorization_code with PKCE (recommended), behaviour that users may already know from similar web applications. Anything that helps prevent users from downloading SaschasAppThatImpersonatesEliesApp instead of EliesApp. I hope this clarifies it. If not, please ask again.
Thanks for good explanation -First Question ) can not the hacker application generate the client ID(code ) like actual app using the same algorithm (which actual application uses to generate the code ) and hack the application with same kind of client code and access token and enter into server application ? question 2 )why can not the OAthu2 itself check/invoke this kind verification process (client code and access token and reduce its TTL of token and code verification),why we need another PKCE ? .Later /future if the hacker is able to crack client code and send duplicate code from hacker application to server application ,this PKCE may come to end or vanish ?please clarify
Hello Jaffer, thanks for taking the time for these questions. Answer for question 1: the generated code_verifier has to have a length of 43-128 characters. The chances of a seconds app generating the same random value, and this during the sessions lifetime, is practically impossible. Therefore, that won't happen. That should also answer your 3. question of PKCE vanishes for that reason. For your 2. question: from a servers point of view there is no indicator that would tell it if the authorization_code is presented by the client that initially received it. Please keep in mind that oauth client instances are duplicates of each other meaning if an oauth app runs on a mobile device there may be millions of copies of the same app/ configuration. I hope this clarifies it. If not, please feel free to come back with a follow up question.
Thanks for this explaination ! I have a genuine question. Why would the OS send response to the wrong mobile app ? In the systems I have seen, the apps(client side) call a url and then expect a response containing the access token (json jwt) , so why should another app receive this access token ? Thanks !
Hello Julien! The OS does not know which app the correct one is. Let's say you and I register an app "JuliensApp", "SaschasApp", and we both register the same customURL: "myapp//duplicate.url.com". Now, an external platform redirects the authorization result to: "my app://duplicate.url.com#access_token=atoken", the OS cannot know if this is meant for "JuliensApp" or "SaschasApp". It will pick one app that was registered for that customUrl. And with that, that app also receives the access_token. I hope this helps! If not, please let me know
@@saschazegerman thanks, so this means that your app is "listening" for a response and not actively fetching data like with this kind of instruction (JS) "Http.getJSON(my_url);"
@@julienlaguitton8339 Actually, the app is being launched by the OS. That app does not know anything about received requests and therefore it is not listing either. Checkout this link for more about this in Android. I hope this helps! developer.android.com/training/app-links/deep-linking
Hello Freejack1982! The refresh_token may not be issued, depending on the provider you are working with. To renew an access_token the user has to re-authenticate during the authorization process. There are certainly exceptions and depend on your provider: - use an id_token as "id_token_hint" with "prompt=none" when requesting a ew access_token if your provider supports those parameters (in the context of OpenID Connect) - cookies that are still valid for the browser session (in cases where that is used) I hope this helps!
@@saschazegerman This helps alot! You just gave me the missing parts I was searching all day long :-) Should have studied the specification in more detail. Anyways, thanks alot!
Hello Sascha, Thank you such a great explanation . I have a few questions 1) Where do you usually store the code verifier for the authorization server to use? 2) If the code challenge method is plain, even hacker app can see and utilize the value. Doesn't this nullify the benefit of PKCE? 3) Can you give me an example of a private client? 4) Would code verifier be sent along with the refresh token?
Hello Amit! Thanks for the feedback! Here are the answers: 1) a javascript client could persist the code_verifier in the local browser storage 2) yes, the method PLAIN does not really help. The reason for its existence is explained here: tools.ietf.org/html/rfc7636#section-4.2. And reasons why not to use/support it are here: tools.ietf.org/html/rfc7636#section-7.2 3) A private (confidential) client could be a web application. For example, the server of 'youtube' is confidential. It is able to keep a secret from being spoofed by any other application 4) no, code_verifier is only used when exchanging the authorization_code for a token (grant_type=authorization_code) You can find a nice javascript client with PKCE implementation here: github.com/aaronpk/pkce-vanilla-js. And my own, poor-mans-version, called 'spa.html' here: github.com/SaschaZeGerman/loginbuddy/tree/master/net.loginbuddy.democlient/web My project 'Loginbuddy' is a confidential application which you can find here: github.com/SaschaZeGerman/loginbuddy. The PKCE implementation is at this location: github.com/SaschaZeGerman/loginbuddy/tree/master/net.loginbuddy.common/src/main/java/net/loginbuddy/common/util I hope this helps!
I guess PKCE is enough for CSRF protection (tools.ietf.org/id/draft-ietf-oauth-security-topics-13.html): > If PKCE [RFC7636] is used by the client and the authorization server supports PKCE, clients MAY opt to not use state for CSRF protection, as such protection is provided by PKCE. In this case, state MAY be used again for its original purpose, namely transporting data about the application state of the client (see Section 4.7.1).
Hello Hamid, thanks for your question ... and answering it :-) This question has also been addressed in the OAuth working group. Yes, if PKCE is used, the state parameter does not need to be used to prevent CSRF attacks. However, an oauth server will not indicate to a client if PKCE is supported or not. Therefore, a developer has to decide for himself to continue to use state for this purpose or not if he is not sure about the servers behaviour. In addition, state should still be used to manage client session data. I hope this helps!
Initially AppA generates a code_verifier and calculates the sha256 value of that (code_challenge=sha256(code_verifier)). The code_verifier is not visible to any other entity. When it sends the plain code_verifier to the /token endpoint is uses SSL. So, in order for AppB to send the code_verifier that AppA generated, it would have to be able to reverse the calculation as in: code_verifer=reverse(code_challenge). If you search for 'how to break sha256' you will find no solution for that. I hope this helps
@@saschazegerman Right, okay, I get it now after googling more. The names "code challenge" & "code verifier" are super confusing, not sure why they chose those names. But regardless of terms, the idea is we provide a hash first, then later on, we provide the source of that hash. This mechanism operates like a password. (Also on your slide for "PKCE to the rescue", you show 2 calls at steps #3 & #4. I thought step #4 was the response we got back from request #3, but I now understand you're saying #4 is the next request WE make after getting a response back from our #3 request.)
@Synthetase2, to clarify this more, I have implemented a super simple javascript client in my open source project Loginbuddy on GitHub. If you look at the script you'll find two important functions. 'authorize', which initializes the authorization code flow. It generates the code_verifier and the code_challenge. It includes the code_challenge in the redirect to the auth server and remembers the code_verifier in its state object. After receiving the authorization_code it executes 'exchangeCode'. This is the request that exchanges the code for a token. And for this request it uses the code_verifier from its state object. It uses POST and SSL. The main difference is that 'authorize' request URL is visible in the browser (public) and the POST request is a back channel request via SSL and therefore confidential. You can find the javascript code here: github.com/SaschaZeGerman/loginbuddy/tree/master/net.loginbuddy.democlient/web/script You can try the client by following this link: 'client.loginbuddy.net'. Select '...SPA' and on the next screen 'Submit'. Now, before doing anything else, copy the URL and you'll find the 'code_challenge. Thanks for your comment!
@@saschazegerman I had a similar question, but you have answered the half of it. To extend further, why cant the App-A directly use SSL+POST while interacting with "authorize" request URL?
Hello Saikumar! The authorization endpoint does support POST, yes. But the servers response, that includes the authorization_code, is still returned via the redirect_uri (custom_uri). And with that the code could still end up in AppB. With native apps it is important to know that they are considered 'public' and with that you have to assume that all client details (such as client_id) are exposed one way or the other, even if not used via a redirect. I just posted a video on client_types, maybe that helps for this topic too. If you have more questions, please do not hesitate!
@@saschazegerman one topic on how to use the refresh token when access token expires , ex : when a user is inactive for long time I need to logout the user can you please explain this in oauth, please?
Hi, thanks for the video. In case the custom url scheme gets returned to hacker app, wouldn't it mean that my app can't process further or will it automatically initiate another request for auth code after some period of time of not receiving response? Also, why can't one use webview and intercept everything oneself? (afaik, there isn't a way for a server to check if one is from webview or real browser, with the further also being another instance of a real mobile browser in the first place) -- I heard enough of people saying, webview is bad practice, at least for implicit flow (which shouldn't be used for mobile apps and is outdated anyways), is it because hacker app could also pretend to be my app by requesting from a webview? Thanks in advance
ANd what is the exact action of my app to incur the custom url scheme / opening it up with a random app (why can''t a hacker app initiate it, since no client secret)? That my app opens the browser with the initial link and the browser subsequently needs to redirect to the redir url, which matches the scheme and when checking against the OS, instead of staying in the browser, (the browser) gets the redir url digested by a random app out of possibly dozens that are registered with such scheme in the OS? But why wouldn't the response of the POST response be intercepted, which on the TCP level is as plain text as GET -- because it doesn't contain any code or token in itself, and/or because this only happens when MY APP gets the first response with the real auth code, hence the worst would be that my app waits and waits and re-initiates another request for auth code with new challenge?
Hello Therence! The problem with WebViews is that the app developer has full control over it. So, the fear is that a developer could easily read, log and misuse any input of an app user. This would include usernames, passwords, whatever it is. For this reason it is not only the wrong solution for implicit flows but for any case where users provide sensitive data. I am walking on thin ice now but I believe and app that uses WebViews in Android for authentication will be denied at the app store .... . The behaviour of your app after not receiving the authorization_code is totally up to you. If your app sends an authorization request you should implement a timeout after which it fails and handle that case. There is no out-of-the box feature that handles it for you. I hope this helps!
Therence, I am not sure if I completely understand this part of the question. In regards to TCP level, please keep in mind that your app communicates via TLS with the server so the messages between your app and the server are encrypted. For iOS, please have a look at Universal Links which should be used in favour over custom url schemes. But, since I have not implemented them myself, I cannot talk too much about them. Please come back with more questions if I could not answer everything.
@@saschazegerman Thank you for your reply! I've seen many libraries that implement code flow integration via webview, and according to your description, wouldn't the harm be at most the same as a phishing app (which would of course also be denied of app store access)? I'm saying at most because, isn't logging webview activities only possible if javascript is injected or messages are passed through the message bridge? A hacker app might do this, granted; but if I were to do it with my own app, would there still be any risk using MY app (in case it indeed gets published to app store) Considering that the only way left would be redirecting to a real browser for login and then returning to the app, the user experience isn't really nice, is it?
If you would built an app just for you, not published to the app store, the WebView itself would not make a difference, right. You will most likely not try to steal the password that you entered yourself. For general use, Chrome Custom Tabs (Android) and Safari View Controller (iOS) are the way to go. The user experience may not be perfect, but it is the only way to avoid credentials being misused. Now, I do not work with mobile apps all the time now, therefore I may not be completely up-to-date with the latest features. But as a rule of thumb, try to avoid implicit flows that return access_token, WebViews when working with sensitive user data. Always use PKCE when leveraging the authorization_code flow. If you are a java-guy, please see this page for more details on WebViews vs. Chrome Custom Tabs: developers.google.com/web/android/custom-tabs
@@saschazegerman Another thing is your voice. We all hold it back a little bit in a corp environment. But when recording your tutorials, you will need to go near 100%. They call it projection. See Clever Programmer's recent videos about running UA-cam channel. He has some great info there. I am by no means affiliated with him. I also run a channel under a different account. Hence learning too.
Hello Dixon! It is nice to see that PAR is a topic for a question! PKCE with PAR behaves just the same as with a default authorization_code flow. As for all other parameters, PKCE params are also included to the PAR endpoint. If you have not watched it, I have a video on PAR: ua-cam.com/video/fE11HJRCL-k/v-deo.html I hope this helps!
Hi Bojan! I am not an expert on quantum computing. But for this particular case the s256 hash would be have to be reversed within an average of 10-30 seconds, as long as the flow takes. I imagine that is unlikely to happen.
@@saschazegerman I'm not an expert either and quick googling reveals conflicting reports on whether or not SHA256 is quantum-safe. In any case, I guess your point stands.
i don't know who else can clearly explain PKCE than you, unless God has other plans. people like you should be writing specs. i tried buying a coffee for you( which is nothing compared to what you are doing to the community ), but I am sorry I could not, for two reasons, one it offers only beer ( i don't buy alcoholic drinks to others when i don't prefer or recommend one , especially for a good teacher) and other reason is that the site is not offering other trusted payment options . may i know are you in Patreon?
Thank you for the great compliment, Selva! In regards to buymeacoffe, I changed it from beer to coffee since you made a good point. I am not currently on patron, I will look into that. Comments like yours are a big encouragement to continue create videos. I actually participate in spec. work (less than I would like to), you'll find my name in FAPI (openid.net/specs/openid-financial-api-part-1-1_0-final.html#acknowledgement)
@@saschazegerman Thank you so much , i am happy to see your name in the FAPI spec. thank you again. God bless you to continue the great work. kindly accept the coffees.
ClientIds are considered public information. What is stopping a hacker from using some reputed clientId in the PKCE flow and have access to all their scopes? Since there is no secret verification involved, the hacker is free to use anyone's client id. Even the consent screen will go off of the client id (some reputed app) and show their name on the consent screen. The user would be misled to believe he/she is giving consent to that reputed clientId. Am I mistaken? Please advise.
Hi paypal! The goal of PKCE is the prevention of a valid authorization_code to be used by a client that did not request it. Your scenario is not addressed by PKCE. I hope this helps.
This is so well explained. I had so many questions and this video has answered them all. Thank you Sascha!
This is a very clean explanation for the PKCE flow. I have bookmarked this UA-cam video. Thank you Sascha!
One of the best videos I’ve seen on PKCE explanation.
Came here after trying to understand what Auth0 was trying to say on their documentation. Thank you sir.
Thanks, you saves me a day with just a 9 minutes video.
I was looking a video to share with my colleagues. Your video is the best I've found to explain how PKCE works.
8:48 very well invested. Thank you Sascha, brilliantly verbalized.
Excelente! Easy to understand, and I like the format; that you covered the flow twice but with a slightly different angle second time. Ty!
The best Video on PKCE till date...thank you🙏
Brief and crystal clear explanation, Thanks !!
There may be funnier explanations on youtube, but this one was the first, I actually did understand. Thanks.
Thanks, Sascha! Do you still need an answer for your first question?
Brilliant explanation! Very clear and to the point. Keep up the good work
Thank You So Much, very clear and professional way of explanation
the greatest explanation of PKCE available on youtube. Thanks for sharing this buddy
Thanks a lot!
very good explanation, thank you! the only further potential attack would be if the malicious app could somehow gain access to the myapp memory to leak the code_verifier, but in this case nothing else would be secure on this operating system anymore ^^
Great explanation of PKCE!
Best PKCE explanation. Thank you.
Great Explanation!!!
Thank you
Such an awesome explanation, thank you very much @Sascha Preibisch.
was able to skip reading rfc7636 thanks to you. :)
Thanks a lot for this clear explanation
Thank you for the video, really well explained.
Thank you!
Great explanation, thank you very much!
Thank you for your helpful video. You've saved me for a couple of hours to searching for this issue :D
Thank you, I am glad I could help!
I understand that Hacker App can not use the stolen Auth Code to get Access Token because of PKCE but - why can't Hacker app use the clientID of your app and generate a code verifier then ask Authorization Server for a Auth Code and then again for Access Code?
Hello Arbaaz! That is a good question and the answer is that this scenario is not the concern of PKCE. If someone would 'copy' an app and register the same redirect_uri, that could happen. However, PKCE can only prevent one app from using another app authorization_code. I hope this helps
Thanks very much for clear explanation
excellent explanation
Great way to explain a relatively complex and important topic.. :thumbs_up:
Best explanation I’ve seen for this topic. Thanks a lot Sasha!!!
Thank you, Dima! I hope I can produce more helping videos in the future
Excellently explained 💪
Doesn't the authorization server check the client_secret before issuing the access token ?
Client B cannot exchange the auth code for an access token because it doesn't have the required client_secret.
Am I missing something here ?
Hello Aditya! That is a good question. Please note that PKCE is meant for public clients. Public clients do not have a client_secret. You may see implementations that carry one but that is practically useless. If you think of javascript, the client_secret is visible in the code in the browser and with that it is not a secret.
I have created a video about client types, maybe that is of interest for you also. I hope this helps, and thanks for the question!
@@saschazegerman ahhh got it! Thank you
thanks for asking this, I was about to post the same thing
Very nice video, explained it very good! Thanks a lot, you saved my ass a little bit. I'm about to hold a OAuth 2.0 Presentation tomorrow and I always wondered how a "dynamic client secret code" is realized. 10/10
Good that it helped! Good luck with your presentation!
very nice explanation
great explanation, thank you
Спасибо за видео! Отличное пошаговое объяснение и примеры. Как же нехватает в некоторых документациях типичных примеров
Кстати, несмотря на то что я плохо знаю английский, для меня видео оказалось понятным
@@Idnt_know Hello! Although my name is Russian, I am German and could help you either in German or English. Can you submit your comment again please, unless it is not meant or me. Thank you
Ok, so I put your comment into translate.google.com and it seem the video was helpful for you. Very good! In regards to examples, have you got a specific use case in mind?
@@saschazegerman Yes, I was talking about examples of "get /authorize" and "post /token" requests. It was very useful for me. Thanks again!
can someone explain why the hacker can access our get request but cant access our post request?
Hi there! Please scroll down and find the second last comment and find my response which answers exactly this question. I hope that helps!
Best explanation!
Thanks a lot. Great explaination
Great explanation. Direct and to the point. Thanks!
Hey! Great explaination thanks.
I have a doubt about something you replied in one of the comments about code_verifier i.e "The POST is sent via SSL between the client and the authorization server, no browser involved.
My doubts:
1.) If code_verifier is exposed to hacker, then PKCE doesn't ensure any security, right?
2.) If the implementation use Single Page Application (SPA) and it is responsible for all the authentication/authorization. In this case the interaction can only happen through browser, and the hacker can get access to code_verifier.
So does PKCE ensure any security in that case?
Hello Pramod! Thank you for the question and thanks for looking into earlier comments. You are right, if the code_verifier gets into the hand of a hacker app PKCE has lost, so to say. But the chances are small and ideally it is a one-time only value meaning the same value can only be used per authorization step. For your second question, I should have said there is no 'browser redirect' involved. Because, as you say, a SPA is running in a browser and therefore the browser is involved. But the main message should have been that the client (JS script client in this case) is connecting to the authorization server directly, via SSL/TLS without exposing any connection details to the browser URL. I hope that clarifies it and I hope that it is what you were expecting.
What if the hacker app doesn't get the authorization code, both authorization code and code verifier are sent to IDP, and the token is sent back but now what if the hacker app gets the token? Is this prevented in any way?
Hello Mustafa! Please keep in mind that the code and verifier are exchanged via SSL directly between the app and the server. The token ends up in the context of the app which lives in its own sandbox. If another app would be able to access any of its data the whole app ecosystem would be compromised. Therefore, the scenario of a stolen access_token in this scenario is unlikely to happen.
However, to answer your question for the general case, as long as the token was issued as a bearer token it can be used by any app that it is possession of it!
On that note, if you have the time, watch my video about implicit flows that touches on that topic also. I hope this helps!
Quick question, wouldnt the attacker be able to intercept the access token the same way he intercepted the auth code?
Hi Mac! No, that is not possible. The authorization_code is returned via a redirect_uri where as the access_token it exchanged via TLS, directly between the app and the auth server. I hope this helps.
Very Nice Explanation
Wow! We developers know how to make things complicated. :)
Yes, that is true! But, unfortunately, in this context it is the simple solution :-)
So perfectly explained!
So why the operating system can lauch the hacker app for the response of the first request but no for the response to token endpoint??
Hello! Imagine it like this (not completely accurate, but good for understanding the difference):
- the authorization_code is delivered to the app like a letter to an apartment building. Imagine a high-rise with 100 apartments but two of those have the same apartment numbers. The letter will end up in one of those two letter boxes. Just like the OS which selects one app having the same redirect_uri.
- The token exchange is more like a phone call between two parties.
I hope this helps!
Thanks, that really made it clear!
Wonderfully explained... If a guy can't understand the concept here.. he'd not be able understand anywhere for sure.
Looking forward to see some long good video on "Proof-of-Possession" please..😊
Very good explained!
Thanks a lot Sasha!
Liked it. Very well explained.
Thanks for the video. It explains in a clear and visual way the value of PKCE. I have one question. Why do you use semicolons instead of dots in the domain, i.e. me:myapp:one:com instead of my.myapp.one.com? Disclaimer: I have little experience with mobile development.
Hello Peter, no problem! If you search for custom schemes you will find that this pattern of using colons (:) for domain names is very typical. Other examples are: myscheme://path.to.my.app. The main point is to find a unique value so that your URL does not clash with others. I hope this helps.
Hi Sascha, thanks for the great video:)
So did I get this right?
Use case for this is using the authorization code flow for systems with public clients that don't have a backend service. Let's say, a calendar app that combines your google, microsoft and apple calendar into one. You wouldn't need a custom backend for that, just the app.
I have 3 questions:
Is auth_code + pkce more or less the replacement for the implicit flow?
With a custom backend you wouldn't need pkce as it has a secret which the auth server knows and uses to validate the token-request instead of the code_verifier, right?
How does pkce help with the calendar app in a browser? An extension could maybe still get the code_verifier, as it has access to a web page's internal javascript.
Hi Boiii! Her are your answer:
- Is auth_code + pkce more or less the replacement for the implicit flow? No, it is complimentary
- With a custom backend you wouldn't need pkce as it has a secret which the auth server knows and uses to validate the token-request instead of the code_verifier, right? Yes, however, it is recommended to use PKCE in any scenario with authorization_code flows
- How does pkce help with the calendar app in a browser? An extension could maybe still get the code_verifier, as it has access to a web page's internal javascript: They run on different domains, right? You need to find a secure location for your code_verifier. Local Storage is probably your obvious choice. Please find more info on best practice for auth apps in browser
I hope this helps!
@@saschazegerman Thanks for the detailed answer, really appreciate it:)
Very nicely explained :)
With the code_challender and code_challenger_method which are public, I could get the code verifier????
Hi Alexis! No, you could not get or extract the code_verifier based on the code_challenge and code_challenge_method (unless the method is PLAIN). The code_verifier is only exchanged via SSL directly with the authorization server. I hope this helps.
I realize this is an old video but if you're still paying attention to comments, I am a little confused about the code verifier.
Does the server know the verifier beforehand?
What keeps the hacker app from sending it's own verifier code,?
Hi Matt! The verifier is generated by the client, on the fly, per authorization request. The hacker would have to be able to derive the verifier from the sha-256 hash of it. The chances are basically 0 to achieve that. For example: this is the base64 encoded hash of a short string and the chances of you figuring out what the sentence is ... probably not going to happen: yWIgwAZPNpBFshwG7lIU2KTFntFQKQ+LRebfFZrBiDQ=. This means, whatever verifier the hacker app sends, the server will use it to regenerated the sha-256 hash of it and it will not match the value that was given to the server in the beginning of the authorization flow. I hope this helps!
How does token refreshing work with PKCE? Same like with regular code flow? Does the refresh process gets also extended by code_challenge and method?
Freejack1982, no, PKCE is not used when refreshing token. It is only specified for the initial authorization code request.
Since you client communicates with the authorization server via SSL directly, the new token are part of the response. There is not party in between you and the authorization server.
Thanks for explanation, although I don't see any value in PKCE especially in authorization code flow since when you are exchanging authorization code for token you use secret key for that which is stored server side only and assure secure exchange...
Hello Eddy, thanks for your thoughts! Unfortunately, for all public clients, such as mobile apps, java script apps, there is no client secret. Your described use case is only valid for confidential clients, such as web apps. I hope this clarifies it more. If not, please come back!
@@saschazegerman Well, this is why they use implicit flow and not the auth. code flow while by definition auth. code flow must be using secret key. But again, not going to argue my point :) Thanks again for investing time in the presentation and taking time to respond
Eddy, the implicit flow returns the access_token directly to the client, attached to the redirect_uri. This means the 'hacker' app would, instead of receiving 'just' the code, would get the access_token which is even worse! Please note that the implicit flow is not supported in the upcoming OAuth 2.1 spec. It is a very risky flow and should be avoided, especially for public apps. The use of the authorization_code should be used instead.
In regards to the authorization_code flow, that can be used with public clients (no client_secret) and confidential client (with client_secret). I also made a video about client_types which may also clarify this topic. Thanks!
@@saschazegerman I know, and completely agree with you. What I meant was that by definition auth. code flow should be used with secret key and if application rely on client side only that it should use implicit flow and then PKCE makes more sense.
Eddy, the current suggestion by the oauth and openid connect working groups is to avoid using the implicit flow! Wherever possible the code flow with PKCE should be used. Here is a good summary: oauth.net/2.1/
Please note that RFC 6749 is not supporting your argument that the code flow should be used with client secrets. Please review paragraph 4.1.3. here: tools.ietf.org/html/rfc6749#section-4.1.3
In addition, PKCE is not defined for implicit flows as I mentioned in my video. Best regards!
God bless you, sir
Thank you very much, Reet! I am glad I could help.
Why use PKCE for private applications that can store secrets (ie the client_secret)? Just in case the secret is exposed?
Hi there! You do not have to, but it is encouraged, it does no harm. It is just one more tool to keep your application and your users data safe.
Nice explanation! Two questions:
1. You mention that hacker app may intercept code_verifier in GET request. What is the mechanism for such interception? Or even not by hacker app, any third party.
2. In POST request that exchanges auth code for access token you have redirect uri. Is it just a typo?
Hello Saggit, thanks for watching the video! The authorization_code may be intercepted by any app that has registered the same redirect_uri (custom_uri) as your own app. The OS will launch one of them, either without notice or by asking the user which one to choose.
For the second question, the redirect_uri is required in the code exchange request (/token) if the initial authorization_code request (/authorize) included included it also.
I hope this helps!
@@saschazegerman Thanks for your reply! Regarding the first question. On the 5:40 mark you say this, referring to code_challenge URL parameter passed in GET request: "the hacker's app may also notice this value, but this doesn't add value to the hacker app, because it is a public value anyway". My question is, why URL parameter in GET request is a public value? What is the mechanism for its interception?
Regarding the second question: all clear now, thank you!
@@saggitt If you look at the URL in a browser, you can see the full string which may include a query parameter. If you read this message, have a look at the URL, it may include ?v=... where v is a parameter. The point I was trying to make is that code_challenge is a value that may be seen by users or programs but has no value to anyone. Therefore, it is safe to include it in the URL. The code_verifier, however, cannot be shared in such a way since it should be a secret between your client and the server. Does this answer your question?
@@saschazegerman Thank you! I just forgot that this GET request is actually done by a browser, not by the app itself. So, for example, a browser extension would be able to read the url. Thanks again!
Thanks a lot! Very nice walkthrough. Could you put the slides in the video description?
On 5:48 you mentioned than code_chalenge can be know by hacker app so why can't he use the same code-chaallege on GET method to get code-verifier. why will he generate random one. Can you please answer this question.
Hello Somappa, thanks for your question! The code_challenge is the result of sha256(code_verifier). The hacker app would need to be able to reverse that operation, something like 'code_verifier=reverseSha256(code_challenge)'. That is not possible. So, although a hacker app could reuse the same code challenge, that app would not be able to exchange the authorization_code for an access_token because it would not be able to provide the code_verifier. I hope this helps, if not, please come back!
ok now i finally get it, thanks!
Great video
Hi Sascha, this is an awesome walk through. Certainly one of the clearest online (I've been working through a couple today). One thing that isn't clear to me, how does the public client prevent the hacker app from getting the code_verifier, code_challenge, and code_challenge_method (either over the network or on the device)? I thought the challenge was that the hacker app can see traffic on the network and the device storage is not secure.
Hi Jesse! Thanks for watching my video! The code_challenge and code_challenge_method are public values, anyone can see them. The code_verifier, however, is the secret between the client and the server. But that is exchanged via the client and the server through TLS and therefore hidden from others. You would need a routed device in order to somehow encrypt those messages.
The main problem that PKCE is preventing is the mis-usage of an authorization_code. I hope this helps!
@@saschazegerman Hi Sascha. But isn't the code from the server transferred to the client to TLS too? Maybe I did not understand the "custom url scheme" thing properly...
@@saschahoppe4833 Yes, but the recipient is the OS, so to say which then forwards it to one of the apps that registered the given custom URL. Does this clarify it?
@@saschazegerman Assume the hacker app gets access_code, what's preventing the hacker app to generate new pair of challenge & it's hash and send that instead to get access token?
@@akshaybhor6330 Thanks for your question. That authorization_code is already bound to the code_challenge which the authorization server remembers. If that authorization_code is exchanged for an access_token, the hack has to use its own code_verifier and that won't match the one that was used to generate the original value. I hope this helps!
Great video - thanks
Thanks a lot!
Thank you for this very good video! The hacker app can't intercept the code_challenge XYZ in the first GET request ?
Hello Ibiza! The code_challenge is a public value and with that any entity may see or use it. However, in the second part of the flow the client has to provide the matching code_verifier which lets the authorization server regenerate the code_challenge. And that is practically impossible. I hope this helps!
@@saschazegerman Thank you for explaining it in a better way. But if code_challange can be intercepted(Assuming by intercepting the Get request or may be by other way ), so in the same way code_verifier cane intercepted? I really can't understand why code_verifier can't be intercepted?
Hello Dheeraj, to abstract this a little more, here is a comparison with public mail. Imagine the code_challenge is sent via post card, everyone can read it. And the post card includes the code_challenge and the hashing method. Afterwards the code_verifier is sent with a letter, inside a sealed envelope. Only the recipient can read the content.
Now, in order for someone to 'fake' being the sender, this someone would have to guess the code_verifier value that was inside the envelope.
This analogy is not 100% true, but the idea behind it is. The post card is the URL in the browser and the envelope represents the encrypted TLS channel used to send the code_verifier. Please let me know if that helps!
@@saschazegerman Thank you for explaining it. Got it now.
Thank you for the great explanation. I do have one question. Wouldn't the hacker app able to intercept the {code_verifier} in the POST method in video playback@ 6:42?
Ooops, I guess my doubt is resolved by https !! correct?
Hello Rabbit Lee! The POST is sent via SSL between the client and the authorization server, no browser involved. That connection is encrypted and therefore the code_Verifier cannot be spoofed or intercepted. This, of course, is only true for devices that have not been rooted (jailbreak). I hope this helps!
@@saschazegerman Well noted with great thanks !!
Okay but what if the returned access token is then taken by the hacker app? or must the identifier be part of every api request to the resource server?
Hello Daniel! The access_token is exchanged via a TLS connection between the client and the authorization server and includes the code_verifier. A hacker app is not able to get in-between that connection. The code_verifier is not used again. I hope this helps!
@@saschazegerman thank you!
nice explanation!
Sehr schön erklärt
Vielen Dank!
Good video, however, I don't believe you explained how S256 and a random string that was generated and also available to both the hacker and the authorization server, in this case, how would the authorization server would be able to process the code verifier any differently when it is sent from the legit app or a hacker app, I wish you would elaborate a bit more on that.
Hi Moses, thanks for your interest in my videos. The random string is not available to the hackers app, only the hash of it. The hackers app would have to "guess" or "steal" the code_verifier in order to send it to the authorization server. The auth_server will use it to regenerate the hash value and compares it to the one given by your app. The hacker app will not be able to provide that code_verifier. I hope this helps, if not, please come back.
@@saschazegerman that explains, thank you!
thanks for your explaination. i want to ask you where can i save the challenge code sent on the authorization request? do i store it in the database?
Hello Fikri! Thanks for watching the video and your question. If you have a server side application you can store the code_verifier as part of the current session. If it is a javascript (SPA) based app you may use the browsers local storage.
This is the reference to my open source project 'Loginbuddy' where I have implemented a very simple SPA: github.com/SaschaZeGerman/loginbuddy/blob/master/net.loginbuddy.democlient/web/script/spa-demo.js
You can see it in action here: client.loginbuddy.net
In any case, it should give you an idea how it works. If not, please let me know.
@@saschazegerman thanks for your answer, i have two question again
1. pkce was created because authorization code is vulnerable to being stolen when the code is sent from server to app. if so, how can i secure the access token when sent by the server to app?
2. if i make a mobile app, where can i store the access token in mobile app?
@@fikrikamal7947 the access_token is exchanged via TLS, directly between your app and the server. That is a secure, private channel. After receiving the access_token you can either keep in memory until the app closes. In that case, your app needs to request a new one each time the app is opened. Another option is to use a public key to encrypt it, and then store it on the phone. When needing it, use the private key to decrypt it. I hope that helps.
@@saschazegerman Why isn't the authorization_token exchanged via TLS?
@@DallasCowboyFan95 Hi there! I am not quite sure if I get the question. The authorization_code is exchanged via TLS, directly between the app and the authorization server. Can you explain a little more, please?
Superb.
Nice explanation thx!
well explained, thanks
Thank you
Great Explaination!!
Sascha, I am using msal-angular and msal-browser packages for implement SSO login which uses OAuth 2.0 - PKCE. So achieved it. But I don't have any idea about refresh token
how to handle.
so can you make video on it or give some suggestion how to implement it in angular app.
Hi Crazyvinee! I have created a video on refresh_token. Please watch it and let me know if you have any question on the usage of it! Thanks!
Nice explanation, but why not simply use RSA to send the public key with the auth request so the app can decrypt it with the private key?
Hi Daniel! Thanks for your question. Do you mean the server should encrypt the authorization_code using the clients public key? For that to work the client would have to generate a key pair at runtime and include the public key in its initial authorization request. Even though that might work, it is most likely more complicated and requires some more developer skills than generating a string-based verifier. The client should preferably also use POST instead of GET when creating the authorization request. However, technically it would work fine I believe. I hope this helps and let me know if you have other thoughts around this.
but what prevents the Hacker App from creating its own code verifier, its own code challenge and to basically reproduce the flow used by MyApp?
Well, the main idea of PKCE is to prevent appB from using an authorization_code issued for appA. PKCE cannot prevent an app to "steal" your client_id and "impersonate" your app. This means you could still technically "clone" a different app.
Therefore, building a public client, which runs on mobile devices, requires very good naming, branding, well chosen redirect_uri(s) (custom uri), authorization_code with PKCE (recommended), behaviour that users may already know from similar web applications. Anything that helps prevent users from downloading SaschasAppThatImpersonatesEliesApp instead of EliesApp. I hope this clarifies it. If not, please ask again.
@@saschazegerman thanks, that makes sense
@@saschazegerman Isn't configuring an allowed request source enough to stop appB?
Hi Andre! Can you elaborate a little more please? Thanks
Great explanation. Plain English helps.
Thanks for good explanation -First Question ) can not the hacker application generate the client ID(code ) like actual app using the same algorithm (which actual application uses to generate the code ) and hack the application with same kind of client code and access token and enter into server application ? question 2 )why can not the OAthu2 itself check/invoke this kind verification process (client code and access token and reduce its TTL of token and code verification),why we need another PKCE ? .Later /future if the hacker is able to crack client code and send duplicate code from hacker application to server application ,this PKCE may come to end or vanish ?please clarify
Hello Jaffer, thanks for taking the time for these questions. Answer for question 1: the generated code_verifier has to have a length of 43-128 characters. The chances of a seconds app generating the same random value, and this during the sessions lifetime, is practically impossible. Therefore, that won't happen. That should also answer your 3. question of PKCE vanishes for that reason. For your 2. question: from a servers point of view there is no indicator that would tell it if the authorization_code is presented by the client that initially received it. Please keep in mind that oauth client instances are duplicates of each other meaning if an oauth app runs on a mobile device there may be millions of copies of the same app/ configuration. I hope this clarifies it. If not, please feel free to come back with a follow up question.
Thanks for this explaination !
I have a genuine question.
Why would the OS send response to the wrong mobile app ?
In the systems I have seen, the apps(client side) call a url and then expect a response containing the access token (json jwt) , so why should another app receive this access token ?
Thanks !
Hello Julien! The OS does not know which app the correct one is. Let's say you and I register an app "JuliensApp", "SaschasApp", and we both register the same customURL: "myapp//duplicate.url.com". Now, an external platform redirects the authorization result to: "my app://duplicate.url.com#access_token=atoken", the OS cannot know if this is meant for "JuliensApp" or "SaschasApp". It will pick one app that was registered for that customUrl. And with that, that app also receives the access_token.
I hope this helps! If not, please let me know
@@saschazegerman thanks, so this means that your app is "listening" for a response and not actively fetching data like with this kind of instruction (JS) "Http.getJSON(my_url);"
@@julienlaguitton8339 Actually, the app is being launched by the OS. That app does not know anything about received requests and therefore it is not listing either. Checkout this link for more about this in Android. I hope this helps! developer.android.com/training/app-links/deep-linking
@@saschazegerman Thanks 👍
Are refresh tokens optional with PKCE or in authorization code grand flow? If the refresh token is missing, how does getting a new access token works?
Hello Freejack1982! The refresh_token may not be issued, depending on the provider you are working with. To renew an access_token the user has to re-authenticate during the authorization process.
There are certainly exceptions and depend on your provider:
- use an id_token as "id_token_hint" with "prompt=none" when requesting a ew access_token if your provider supports those parameters (in the context of OpenID Connect)
- cookies that are still valid for the browser session (in cases where that is used)
I hope this helps!
@@saschazegerman This helps alot! You just gave me the missing parts I was searching all day long :-) Should have studied the specification in more detail. Anyways, thanks alot!
Great to hear that! Good luck with your project!
@@saschazegerman Thanks, Sascha.
Hello Sascha,
Thank you such a great explanation
.
I have a few questions
1) Where do you usually store the code verifier for the authorization server to use?
2) If the code challenge method is plain, even hacker app can see and utilize the value. Doesn't this nullify the benefit of PKCE?
3) Can you give me an example of a private client?
4) Would code verifier be sent along with the refresh token?
Hello Amit! Thanks for the feedback! Here are the answers:
1) a javascript client could persist the code_verifier in the local browser storage
2) yes, the method PLAIN does not really help. The reason for its existence is explained here: tools.ietf.org/html/rfc7636#section-4.2. And reasons why not to use/support it are here: tools.ietf.org/html/rfc7636#section-7.2
3) A private (confidential) client could be a web application. For example, the server of 'youtube' is confidential. It is able to keep a secret from being spoofed by any other application
4) no, code_verifier is only used when exchanging the authorization_code for a token (grant_type=authorization_code)
You can find a nice javascript client with PKCE implementation here: github.com/aaronpk/pkce-vanilla-js.
And my own, poor-mans-version, called 'spa.html' here: github.com/SaschaZeGerman/loginbuddy/tree/master/net.loginbuddy.democlient/web
My project 'Loginbuddy' is a confidential application which you can find here: github.com/SaschaZeGerman/loginbuddy. The PKCE implementation is at this location: github.com/SaschaZeGerman/loginbuddy/tree/master/net.loginbuddy.common/src/main/java/net/loginbuddy/common/util
I hope this helps!
In order to prevent CSRF, do we still need state parameter if the OAuth server makes PKCE mandatory for all clients?
I guess PKCE is enough for CSRF protection (tools.ietf.org/id/draft-ietf-oauth-security-topics-13.html):
> If PKCE [RFC7636] is used by the client and the authorization server supports PKCE, clients MAY opt to not use state for CSRF protection, as such protection is provided by PKCE. In this case, state MAY be used again for its original purpose, namely transporting data about the application state of the client (see Section 4.7.1).
Hello Hamid, thanks for your question ... and answering it :-) This question has also been addressed in the OAuth working group. Yes, if PKCE is used, the state parameter does not need to be used to prevent CSRF attacks. However, an oauth server will not indicate to a client if PKCE is supported or not. Therefore, a developer has to decide for himself to continue to use state for this purpose or not if he is not sure about the servers behaviour. In addition, state should still be used to manage client session data.
I hope this helps!
I missed something here: why can only AppA solve for sha256(x) = ? What prevents AppB from being able to calculate this as well?
Initially AppA generates a code_verifier and calculates the sha256 value of that (code_challenge=sha256(code_verifier)). The code_verifier is not visible to any other entity. When it sends the plain code_verifier to the /token endpoint is uses SSL.
So, in order for AppB to send the code_verifier that AppA generated, it would have to be able to reverse the calculation as in: code_verifer=reverse(code_challenge).
If you search for 'how to break sha256' you will find no solution for that. I hope this helps
@@saschazegerman Right, okay, I get it now after googling more. The names "code challenge" & "code verifier" are super confusing, not sure why they chose those names. But regardless of terms, the idea is we provide a hash first, then later on, we provide the source of that hash. This mechanism operates like a password. (Also on your slide for "PKCE to the rescue", you show 2 calls at steps #3 & #4. I thought step #4 was the response we got back from request #3, but I now understand you're saying #4 is the next request WE make after getting a response back from our #3 request.)
@Synthetase2, to clarify this more, I have implemented a super simple javascript client in my open source project Loginbuddy on GitHub. If you look at the script you'll find two important functions. 'authorize', which initializes the authorization code flow. It generates the code_verifier and the code_challenge. It includes the code_challenge in the redirect to the auth server and remembers the code_verifier in its state object.
After receiving the authorization_code it executes 'exchangeCode'. This is the request that exchanges the code for a token. And for this request it uses the code_verifier from its state object. It uses POST and SSL.
The main difference is that 'authorize' request URL is visible in the browser (public) and the POST request is a back channel request via SSL and therefore confidential.
You can find the javascript code here: github.com/SaschaZeGerman/loginbuddy/tree/master/net.loginbuddy.democlient/web/script
You can try the client by following this link: 'client.loginbuddy.net'. Select '...SPA' and on the next screen 'Submit'. Now, before doing anything else, copy the URL and you'll find the 'code_challenge.
Thanks for your comment!
@@saschazegerman I had a similar question, but you have answered the half of it. To extend further, why cant the App-A directly use SSL+POST while interacting with "authorize" request URL?
Hello Saikumar! The authorization endpoint does support POST, yes. But the servers response, that includes the authorization_code, is still returned via the redirect_uri (custom_uri). And with that the code could still end up in AppB.
With native apps it is important to know that they are considered 'public' and with that you have to assume that all client details (such as client_id) are exposed one way or the other, even if not used via a redirect.
I just posted a video on client_types, maybe that helps for this topic too.
If you have more questions, please do not hesitate!
Can you please do a video on when to use JWT as a token format or access token which is a bearer token with OAuth 2.0 ?
Hi there, just noticed your comment! I will start doing new videos mid October and I will include that topic. Thanks for suggesting it.
well done!
Great, more videos please
For sure! Any specific topic on OAuth or OpenID Connect
@@saschazegerman one topic on how to use the refresh token when access token expires , ex : when a user is inactive for long time I need to logout the user can you please explain this in oauth, please?
I am on it!
@@saschazegerman Thank you :)
Hi, thanks for the video. In case the custom url scheme gets returned to hacker app, wouldn't it mean that my app can't process further or will it automatically initiate another request for auth code after some period of time of not receiving response? Also, why can't one use webview and intercept everything oneself? (afaik, there isn't a way for a server to check if one is from webview or real browser, with the further also being another instance of a real mobile browser in the first place) -- I heard enough of people saying, webview is bad practice, at least for implicit flow (which shouldn't be used for mobile apps and is outdated anyways), is it because hacker app could also pretend to be my app by requesting from a webview? Thanks in advance
ANd what is the exact action of my app to incur the custom url scheme / opening it up with a random app (why can''t a hacker app initiate it, since no client secret)? That my app opens the browser with the initial link and the browser subsequently needs to redirect to the redir url, which matches the scheme and when checking against the OS, instead of staying in the browser, (the browser) gets the redir url digested by a random app out of possibly dozens that are registered with such scheme in the OS? But why wouldn't the response of the POST response be intercepted, which on the TCP level is as plain text as GET -- because it doesn't contain any code or token in itself, and/or because this only happens when MY APP gets the first response with the real auth code, hence the worst would be that my app waits and waits and re-initiates another request for auth code with new challenge?
Hello Therence!
The problem with WebViews is that the app developer has full control over it. So, the fear is that a developer could easily read, log and misuse any input of an app user. This would include usernames, passwords, whatever it is. For this reason it is not only the wrong solution for implicit flows but for any case where users provide sensitive data. I am walking on thin ice now but I believe and app that uses WebViews in Android for authentication will be denied at the app store .... .
The behaviour of your app after not receiving the authorization_code is totally up to you. If your app sends an authorization request you should implement a timeout after which it fails and handle that case. There is no out-of-the box feature that handles it for you.
I hope this helps!
Therence,
I am not sure if I completely understand this part of the question. In regards to TCP level, please keep in mind that your app communicates via TLS with the server so the messages between your app and the server are encrypted.
For iOS, please have a look at Universal Links which should be used in favour over custom url schemes. But, since I have not implemented them myself, I cannot talk too much about them.
Please come back with more questions if I could not answer everything.
@@saschazegerman Thank you for your reply! I've seen many libraries that implement code flow integration via webview, and according to your description, wouldn't the harm be at most the same as a phishing app (which would of course also be denied of app store access)? I'm saying at most because, isn't logging webview activities only possible if javascript is injected or messages are passed through the message bridge? A hacker app might do this, granted; but if I were to do it with my own app, would there still be any risk using MY app (in case it indeed gets published to app store)
Considering that the only way left would be redirecting to a real browser for login and then returning to the app, the user experience isn't really nice, is it?
If you would built an app just for you, not published to the app store, the WebView itself would not make a difference, right. You will most likely not try to steal the password that you entered yourself.
For general use, Chrome Custom Tabs (Android) and Safari View Controller (iOS) are the way to go. The user experience may not be perfect, but it is the only way to avoid credentials being misused.
Now, I do not work with mobile apps all the time now, therefore I may not be completely up-to-date with the latest features. But as a rule of thumb, try to avoid implicit flows that return access_token, WebViews when working with sensitive user data. Always use PKCE when leveraging the authorization_code flow.
If you are a java-guy, please see this page for more details on WebViews vs. Chrome Custom Tabs: developers.google.com/web/android/custom-tabs
Thank you sir! You explain things really clearly! Why not make your thumbnails look better? That should help with the growth of your channel
Frank, thank you for that idea! I will work on that.
@@saschazegerman Another thing is your voice. We all hold it back a little bit in a corp environment. But when recording your tutorials, you will need to go near 100%. They call it projection. See Clever Programmer's recent videos about running UA-cam channel. He has some great info there. I am by no means affiliated with him. I also run a channel under a different account. Hence learning too.
@@frankliu5194 Thank you! Feedback and tips are always welcome!
So few like indicates that how little people know about it.
Thanks Sascha, how would this work for PAR?
Hello Dixon! It is nice to see that PAR is a topic for a question! PKCE with PAR behaves just the same as with a default authorization_code flow. As for all other parameters, PKCE params are also included to the PAR endpoint. If you have not watched it, I have a video on PAR: ua-cam.com/video/fE11HJRCL-k/v-deo.html
I hope this helps!
Thanks @@saschazegerman ! Which subsequent call does the client pass the code_verifier? Is it in /authorize or /token?
@@dixonduong8375 That is in /token. With PAR the only real difference is how the flow starts off! The rest is practically the same.
@@saschazegerman Appreciate the info and the videos :)
@@dixonduong8375 Thank you!
thanks.
All of this is fine and dandy until quantum computing takes off and sha256 becomes reversible.
Hi Bojan! I am not an expert on quantum computing. But for this particular case the s256 hash would be have to be reversed within an average of 10-30 seconds, as long as the flow takes. I imagine that is unlikely to happen.
@@saschazegerman I'm not an expert either and quick googling reveals conflicting reports on whether or not SHA256 is quantum-safe.
In any case, I guess your point stands.
i don't know who else can clearly explain PKCE than you, unless God has other plans. people like you should be writing specs. i tried buying a coffee for you( which is nothing compared to what you are doing to the community ), but I am sorry I could not, for two reasons, one it offers only beer ( i don't buy alcoholic drinks to others when i don't prefer or recommend one , especially for a good teacher) and other reason is that the site is not offering other trusted payment options . may i know are you in Patreon?
Thank you for the great compliment, Selva! In regards to buymeacoffe, I changed it from beer to coffee since you made a good point. I am not currently on patron, I will look into that. Comments like yours are a big encouragement to continue create videos.
I actually participate in spec. work (less than I would like to), you'll find my name in FAPI (openid.net/specs/openid-financial-api-part-1-1_0-final.html#acknowledgement)
@@saschazegerman Thank you so much , i am happy to see your name in the FAPI spec. thank you again. God bless you to continue the great work. kindly accept the coffees.
ClientIds are considered public information. What is stopping a hacker from using some reputed clientId in the PKCE flow and have access to all their scopes? Since there is no secret verification involved, the hacker is free to use anyone's client id.
Even the consent screen will go off of the client id (some reputed app) and show their name on the consent screen. The user would be misled to believe he/she is giving consent to that reputed clientId.
Am I mistaken? Please advise.
Hi paypal! The goal of PKCE is the prevention of a valid authorization_code to be used by a client that did not request it. Your scenario is not addressed by PKCE. I hope this helps.