How does OAuth 2 protect against things like replay attacks using the Security Token

Question

As I understand it  the following chain of events occurs in OAuth 2 in order for Site-A to access User s information from Site-B    Site-A registers on Site-B  and obtains a Secret and an ID  When User tells Site-A to access Site-B  User is sent to Site-B where they tell Site-B that they would indeed like to give Site-A permissions to specific information  Site-B redirects User back to Site-A  along with an Authorization Code  Site-A then passes that Authorization Code along with its Secret back to Site-B in return for a Security Token   Site-A then makes requests to Site-B on behalf of User by bundling the Security Token along with requests    How does all of this work in terms of security and encryption  on a high level  How does OAuth 2 protect against things like replay attacks using the Security Token

User · Answer

Figure 1  lifted from RFC6750         --------                                 ---------------                 -- A - Authorization Request - gt     Resource                                                          Owner                       lt - B -- Authorization Grant ---                                                                 ---------------                                                                 ---------------                 -- C -- Authorization Grant -- gt   Authorization          Client                                       Server                      lt - D ----- Access Token -------                                                                 ---------------                                                                 ---------------                 -- E ----- Access Token ------ gt      Resource                                                         Server                      lt - F --- Protected Resource ---                        --------                                 ---------------

User · Answer

OAuth is a protocol with which a 3-party app can access your data stored in another website without your account and password  For a more official definition  refer to the Wiki or specification    Here is a use case demo    I login to LinkedIn and want to connect some friends who are in my Gmail contacts  LinkedIn supports this   It will request a secure resource  my gmail contact list  from gmail   So I click this button   A web page pops up  and it shows the Gmail login page  when I enter my account and password   Gmail then shows a consent page where I click  Accept     Now LinkedIn can access my contacts in Gmail     Below is a flowchart of the example above     Step 1  LinkedIn requests a token from Gmail s Authorization Server   Step 2  The Gmail authorization server authenticates the resource owner and shows the user the consent page   the user needs to login to Gmail if they are not already logged-in   Step 3  User grants the request for LinkedIn to access the Gmail data   Step 4  the Gmail authorization server responds back with an access token   Step 5  LinkedIn calls the Gmail API with this access token   Step 6  The Gmail resource server returns your contacts if the access token is valid   The token will be verified by the Gmail resource server   You can get more from details about OAuth here

User · Answer

Based on what I ve read  this is how it all works   The general flow outlined in the question is correct  In step 2  User X is authenticated  and is also authorizing Site A s access to User X s information on Site B  In step 4  the site passes its Secret back to Site B  authenticating itself  as well as the Authorization Code  indicating what it s asking for  User X s access token    Overall  OAuth 2 actually is a very simple security model  and encryption never comes directly into play  Instead  both the Secret and the Security Token are essentially passwords  and the whole thing is secured only by the security of the https connection   OAuth 2 has no protection against replay attacks of the Security Token or the Secret  Instead  it relies entirely on Site B being responsible with these items and not letting them get out  and on them being sent over https while in transit  https will protect URL parameters    The purpose of the Authorization Code step is simply convenience  and the Authorization Code is not especially sensitive on its own  It provides a common identifier for User X s access token for Site A when asking Site B for User X s access token  Just User X s user id on Site B would not have worked  because there could be many outstanding access tokens waiting to be handed out to different sites at the same time

User · Answer

The other answer is very detailed and addresses the bulk of the questions raised by the OP   To elaborate  and specifically to address the OP s question of  How does OAuth 2 protect against things like replay attacks using the Security Token    there are two additional protections in the official recommendations for implementing OAuth 2   1  Tokens will usually have a short expiration period  http   tools ietf org html rfc6819 section-5 1 5 3       A short expiration time for tokens is a means of protection against   the following threats          replay         2  When the token is used by Site A  the recommendation is that it will be presented not as URL parameters but in the Authorization request header field  http   tools ietf org html rfc6750       Clients SHOULD make authenticated requests with a bearer token using   the  Authorization  request header field with the  Bearer  HTTP   authorization scheme             The  application x-www-form-urlencoded  method SHOULD NOT be used   except in application contexts where participating browsers do not   have access to the  Authorization  request header field             URI Query Parameter    is included to document current use  its use is not   recommended  due to its security deficiencies

User · Answer

How OAuth 2 0 works in real life   I was driving by Olaf s bakery on my way to work when I saw the most delicious donut in the window -- I mean  the thing was dripping chocolatey goodness  So I went inside and demanded  I must have that donut    He said  sure that will be  30     Yeah I know   30 for one donut  It must be delicious  I reached for my wallet when suddenly I heard the chef yell  NO  No donut for you   I asked  why  He said he only accepts bank transfers   Seriously  Yep  he was serious  I almost walked away right there  but then the donut called out to me   Eat me  I m delicious      Who am I to disobey orders from a donut  I said ok   He handed me a note with his name on it  the chef  not the donut    Tell them Olaf sent you   His name was already on the note  so I don t know what the point of saying that was  but ok   I drove an hour and a half to my bank  I handed the note to the teller  I told her Olaf sent me  She gave me one of those looks  the kind that says   I can read    She took my note  asked for my id  asked me how much money was ok to give him  I told her  30 dollars  She did some scribbling and handed me another note  This one had a bunch of numbers on it  I guessed that s how they keep track of the notes   At that point I m starving  I rushed out of there  an hour and a half later I was back  standing in front of Olaf with my note extended  He took it  looked it over and said   I ll be back    I thought he was getting my donut  but after 30 minutes I started to get suspicious  So I asked the guy behind the counter  Where s Olaf    He said  He went to get money    What do you mean     He take note to bank    Huh    so Olaf took the note that the bank gave me and went back to the bank to get money out of my account  Since he had the note the bank gave me  the bank knew he was the guy I was talking about  and because I spoke with the bank they knew to only give him  30   It must have taken me a long time to figure that out because by the time I looked up  Olaf was standing in front of me finally handing me my donut  Before I left I had to ask   Olaf  did you always sell donuts this way     No  I used to do it different    Huh  As I was walking back to my car my phone rang  I didn t bother answering  it was probably my job calling to fire me  my boss is such a      Besides  I was caught up thinking about the process I just went through    I mean think about it  I was able to let Olaf take  30 out of my bank account without having to give him my account information  And I didn t have to worry that he would take out too much money because I already told the bank he was only allowed to take  30  And the bank knew he was the right guy because he had the note they gave me to give to Olaf   Ok  sure I would rather hand him  30 from my pocket  But now that he had that note I could just tell the bank to let him take  30 every week  then I could just show up at the bakery and I didn t have to go to the bank anymore  I could even order the donut by phone if I wanted to   Of course I d never do that -- that donut was disgusting   I wonder if this approach has broader applications  He mentioned this was his second approach  I could call it Olaf 2 0  Anyway I better get home  I gotta start looking for a new job  But not before I get one of those strawberry shakes from that new place across town  I need something to wash away the taste of that donut

User · Answer

This is how Oauth 2 0 works  well explained in this article

User · Answer

Here is perhaps the simplest explanation of how OAuth2 works for all 4 grant types  i e   4 different flows where the app can acquire the access token   Similarity  All grant type flows have 2 parts    Get access token Use access token   The 2nd part  use access token  is the same for all flows  Difference  The 1st part of the flow  get access token  for each grant type varies   However  in general the  get access token  part can be summarized as consisting 5 steps    Pre-register your app  client  with OAuth provider  e g   Twitter  etc  to get client id secret Create a social login button with client id  amp  required scopes permissions on your page so when clicked user gets redirected to OAuth provider to be authenticated OAuth provider request user to grant permission to your app  client  OAuth provider issues code App  client  acquires access token   Here is a side-by-side diagram comparing how each grant type flow is different based on the 5 steps   This diagram is from https   blog oauth io introduction-oauth2-flow-diagrams     Each have different levels of implementation difficulty  security  and uses cases  Depending on your needs and situation  you will have to use one of them  Which to use   Client Credential  If your app is only serving a single user  Resource Owner Password Crendential  This should be used only as last resort as the user has to hand over his credentials to the app  which means the app can do everything the user can  Authorization Code  The best way to get user authorization  Implicit  If you app is mobile or single-page app  There is more explanation of the choice here  https   blog oauth io choose-oauth2-flow-grant-types-for-app

User · Answer

This is a gem   https   www digitalocean com community tutorials an-introduction-to-oauth-2  Very brief summary   OAuth defines four roles    Resource Owner  Client Resource Server Authorization Server   You  Resource Owner  have a mobile phone  You have several different email accounts  but you want all your email accounts in one app  so you don t need to keep switching  So your GMail  Client  asks for access  via Yahoo s Authorization Server  to your Yahoo emails  Resource Server  so you can read both emails on your GMail application   The reason OAuth exists is because it is unsecure for GMail to store your Yahoo username and password

[oauth-2.0] How does OAuth 2 protect against things like replay attacks using the Security Token?

Examples related to oauth-2.0