See the benefits of OAuth 2.0 technology and get an introduction to how it works. To explore introductory videos about InterSystems technologies, visit the featured overviews page on our Learning website: learning.inter...
The workflow diagram does not distinguish between front channel (appbank) and back channel communication (app's serverbank). I.e. from the description it's hard to understand why Memorial Bank doesn't send the Access Token directly (and skips the additional Authorisation Grant round-trip). The explanation is that the first round-trip happens on the front-channel (appbank), however, the 2nd round-trip happens on the back-channel (app serverbank). I.e. the app (the web browser) never sees the Access Token (at least in case of the Authorisation Code Grant flow described in this video).
If I understand correctly it's an extra technical detail. Of which there are probably even more, which are relevant when you're actually there trying to implement the thing. Which may not be the scope of this video, so this higher abstractional level might not be by chance. When your granny asks what you do for work you don't go into all the details do you.
This is the best video of OAuth 2.0 I've found so far. My only request is if there was another screen showing how the client ID, client secret and callback URL are integrated into the flow shown at 4:00.
Wow, amazing how some people can explain complex technology in such a simple way. As my friend A.Einstein said, "If you cant explain it simply, you dont understand it well enough".
In a very superficial way. If you would have been requested to implement an App authentication with this knowledge - Would you know how to? For me it's insufficient.
True but 50% of the burden is on the listener to be interested. A disinterested or just plain stupid one may claim an explanation isn't clear as well. That's the trouble with maxims.
This is overview, implementing is details. If you read only documentation for details, it is surprising hard to understand and get whole picture, because such documentations assumes that reader already understands whole picture.
Others make a 30 minutes long video and can't do shit. Thanks to you for being able to explain it in much shorter time and in the most comprehensive way.
Amazing explanation! I read the actual specification (which is also amazing) but for people looking for a spot-on basic walkthrough of OAuth’s Authorization Code flow, this is it!
In the example, when Sarah access the app's portal (to see bank's balance) for the 1st time, she needs to tell the username/password for the bank. correct? Otherwise, the authorization server would not be able to tell to whom the access token will be issued.
Yes Sarah need to be authenticated. OAUTH 2.0 flow does not include authentication. Authentication can be done in any of the ways like SAML. Yes, for sure Sarah need to authenticate to memorial bank.
This is a great video with easy explanation of how oauth 2.0 is used. It does mention the use of openid for authentication but i guess that happens with the identity provider resource.
I am not sure how the resource server check the access token. The resource server will make request to auth. server for check the access token or resource server has the secret-key (solt) for check the signature of the access token?
Why is can't the authorization server just send back the access token once the user authenticates/authorizes the app? What's the benefit of having an authorization grant passed around before the access token is granted?
sending back access token directly to client is another authorization grant type mentioned in oauth 2.0 framework of ietf, named "implicit". "The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly (as the result of the resource owner authorization). The grant type is implicit as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token). When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent." The implicit way ( send back access token to client/resource owner directly ) will expose access token to resource owner, which is simplified but not reasonable.
This video is very basic if you are asking this type of question.. but let me answer: access_token is not passed directly because we don't want the user to get to see the access_token, why? because user level is never trusted, or he may deplete our API quota by doing calls by himself or If a hacker is sitting in the user code or the application, he can grab the access_token which is bad, he now sees the "code" but this code is nothing without client_id and secret which are perfectly safe (at least under your control) You may say if a hacker is sittin on client side, he can also grab directly the facebook password, this is not always true depending on the hacker type.. if there is an xss vulnerability on your website he can grab the "code" but cannot intervene to facebook login.
Where is the login from Sarah at the Memorail Bank which she have to proceed? Without the login at the memorial bank, they dont knwo which token belongs to which account.
in the case, Sarah have accounts in different banks, not only at Memorial Bank, so how is the process of authorization between MyBucks and all the banks?
To watch multiple movies, we need ticket for each movie. Same goes here i.e. Sarah need to share Name, Web Site and Call back URL to the other banks that have her accounts.
You said Sarah can login only 1 time to access many of her banks. But doesn't she need fill out many consent forms ? Or to be able to achieve this, a different grant other than authorization code need to be used?
exactly my thoughts too.. it said Sarah needs to login JUST ONCE to access all of her account information across various banks.. is it really a valid statement? having been a user of acorns, i think the practical approach would be once per bank account? more of a one time setup per bank till Sarah changes her creds with the bank.. did you ever happen to receive a reply on this one from the content creator?
A great Explanation, I have a small doubt How Resource server validate the token? Does resource server internally communicate with Authorization Server, As i know authorization server refresh the token after some time span, How Resource server come to know refresh token is valid? Please help
I would like to tentatively point out a typo/mistake. At @0:43 you say the API has an authentication server and a resource server. I believe you meant to say that the API has an authorization server and a resource server. The other diagrams show authorization server. Hoping the author sees this and can confirm.
If the authorisation server and the resource server are separate, how does the resource server know that token is legit since there's no "session" shared between them?
The application would have client Id and Client Secret. Using client Id and client secret, response would be decoded, and access token would be retrieved. This access taken would later be used to get resource.
How does the server know that it is "Sarah" making the request, since user credentials arent send along the calls. What prevents the "MyBucks" application from making calls for other users besides "Sarah".
Sarah has to put in her username and password in memorial bank if she hasn't logged into that yet in the auth request phase. I'm betting the access token identifies Sarah which MyBucks application uses the grant to get it. The resource server will deserialize (decode) the access token and figure out its Sarah. If there is any modifications in the token, I'm guessing it will become an invalid token. The Auth server has a key to encode the token and the resource server has a key to decode the token. These are known as private and public keys. I don't remember which one encodes and which one decodes xD
Can this be used just to authenticate a user into your application using your api? It seems to be used for 3rd party verification, but what about your own app?
Missing a critical info here. If you just send the auth code, you will not get access token. The auth code need to go in with nonce & code verifier. Only then the server can authenticate you
