If I have a website (with its own frontend and backend on its own domain) and I am not looking to grant access to third-party apps or pages, is it safe to use credentials flow (username/password)? For example, imagine a small library that wants to save users in its own system and allow them to access their account to see information related to the books they have borrowed, returned, read, etc.
Hi there, thanks for your question. 'Official' reasons for not using this grant_type can be found here: datatracker.ietf.org/doc/html/rfc6819#section-4.4.3 In your scenario the library should use an access_token that was granted via an authorization_code flow. That way, users can decide 'yes' or 'no' to requested access. With that, the access_token can also be limited to exactly what the client should be able to view in a users account. If you are the only developer, if all of this is your application, if you are managing users credentials in your own directory, then the usage is not too terrible. However, please refer to that link to get a broader view on potential challenges. I hope this helps.
perfect man, awesome explanation.the thing that you just mentioned about a root device that a malicious app could audit traffic and extract resource owner credentials, i think that would be the case with the internal Browser as well, don't you think so as well? cause at the end of the day, a root device could audit all the https traffic by any app.
Hello Nathan! The only use case for using the password flow is, in fact, your case. The authorization server and the mobile app (which I think you were referring to) belong to the same domain, were built and are maintained by the same entity. However, the main risk still exists, the app could run on a vulnerable device which may cause the user credentials to leak or be provided to the wrong app. The current draft of the upcoming OAuth 2.1 specification does not support his flow anymore. If you can, use the authorization code flow. I hope this helps!
@@saschazegerman Nice. Thanks for the response. I've implemented the PKCE flow as a test. I'm not sure about the UX, but granted the security is better.
@@saschazegerman "The current draft of the upcoming OAuth 2.1 specification does not support his flow anymore" -but why? because it's not really about "federation of the identity"? Or in other words. Can we still concider it as secure but just not part of OAuth2.1 (not focus anymore?)
@@aholbreich2803 It is not as much about federation as it is about potential security issues. You have to ask yourself: "if Sascha provided a banking management app, would I be willing to share my online banking credentials and account details with it?". The problem is that users may share usernames and passwords with an app. For once, potentially the app could misuse that info. The other problem is that users may share the credentials with a similar, look-a-like app, so to say. Please let me know if this helps!
@@saschazegerman Thank you for answering. Consider banking app that already has user with his credentials, his money, huge set of personal data. Let's say users uses web portal. Besides "banking" example there are a lot "user silos" out there that are building business/app around their user bases. But let's consider i'm bank "A". I have you acount, i have you'r passworts and other stuff and now i offer you a new App.
If I have a website (with its own frontend and backend on its own domain) and I am not looking to grant access to third-party apps or pages, is it safe to use credentials flow (username/password)?
For example, imagine a small library that wants to save users in its own system and allow them to access their account to see information related to the books they have borrowed, returned, read, etc.
Hi there, thanks for your question. 'Official' reasons for not using this grant_type can be found here: datatracker.ietf.org/doc/html/rfc6819#section-4.4.3
In your scenario the library should use an access_token that was granted via an authorization_code flow. That way, users can decide 'yes' or 'no' to requested access. With that, the access_token can also be limited to exactly what the client should be able to view in a users account.
If you are the only developer, if all of this is your application, if you are managing users credentials in your own directory, then the usage is not too terrible. However, please refer to that link to get a broader view on potential challenges. I hope this helps.
Oh, and please look at other questions and answers of this video.
perfect man, awesome explanation.the thing that you just mentioned about a root device that a malicious app could audit traffic and extract resource owner credentials, i think that would be the case with the internal Browser as well, don't you think so as well? cause at the end of the day, a root device could audit all the https traffic by any app.
Hi there, thanks for watching the video. Yes, on a rooted device all bets are off, no matter what.
Great, you open my mind with the hacker app duplication
What if I own both the mobile devise and the authorization server? Is this still a risky flow?
Hello Nathan! The only use case for using the password flow is, in fact, your case. The authorization server and the mobile app (which I think you were referring to) belong to the same domain, were built and are maintained by the same entity. However, the main risk still exists, the app could run on a vulnerable device which may cause the user credentials to leak or be provided to the wrong app. The current draft of the upcoming OAuth 2.1 specification does not support his flow anymore. If you can, use the authorization code flow. I hope this helps!
@@saschazegerman Nice. Thanks for the response. I've implemented the PKCE flow as a test. I'm not sure about the UX, but granted the security is better.
@@saschazegerman "The current draft of the upcoming OAuth 2.1 specification does not support his flow anymore" -but why? because it's not really about "federation of the identity"? Or in other words. Can we still concider it as secure but just not part of OAuth2.1 (not focus anymore?)
@@aholbreich2803 It is not as much about federation as it is about potential security issues. You have to ask yourself: "if Sascha provided a banking management app, would I be willing to share my online banking credentials and account details with it?". The problem is that users may share usernames and passwords with an app. For once, potentially the app could misuse that info. The other problem is that users may share the credentials with a similar, look-a-like app, so to say. Please let me know if this helps!
@@saschazegerman Thank you for answering. Consider banking app that already has user with his credentials, his money, huge set of personal data. Let's say users uses web portal. Besides "banking" example there are a lot "user silos" out there that are building business/app around their user bases.
But let's consider i'm bank "A". I have you acount, i have you'r passworts and other stuff and now i offer you a new App.
Clear explanation. Thanks.
can i get configuration on aws link to implement with cognito?
I am not a Cognito expert, but I believe that flow is not supported. What exactly are you looking for? Thanks
「もっと多くの人が必要なので、このビデオをもっと