56°F 9:44am

Aaron Parecki

  • Articles
  • Notes
  • Projects
  • OAuth 2 Simplified

    This post describes OAuth 2.0 in a simplified format to help developers and service providers implement the protocol.

    The OAuth 2 spec can be a bit confusing to read, so I've written this post to help describe the terminology in a simplified format. The core spec leaves many decisions up to the implementer, often based on security tradeoffs of the implementation. Instead of describing all possible decisions that need to be made to successfully implement OAuth 2, this post makes decisions that are appropriate for most implementations.

    Note: This post has been updated from the original 2012 version based on the current best practices of OAuth 2.0. The original version can be found here.

    Table of Contents

    • Roles: Applications, APIs and Users
    • Creating an App
    • Authorization: Obtaining an access token
      • Web Server Apps
      • Single-Page Apps
      • Mobile Apps
      • Other Grant Types
    • Making Authenticated Requests
    • Differences from OAuth 1.0
      • Authentication and Signatures
      • User Experience and Alternative Authorization Flows
      • Performance at Scale
    • Resources

    Roles

    The Third-Party Application: "Client"

    The client is the application that is attempting to get access to the user's account. It needs to get permission from the user before it can do so.

    The API: "Resource Server"

    The resource server is the API server used to access the user's information.

    The Authorization Server

    This is the server that presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.

    The User: "Resource Owner"

    The resource owner is the person who is giving access to some portion of their account.

    Creating an App

    Before you can begin the OAuth process, you must first register a new app with the service. When registering a new app, you usually register basic information such as application name, website, a logo, etc. In addition, you must register a redirect URI to be used for redirecting users to for web server, browser-based, or mobile apps.

    Redirect URIs

    The service will only redirect users to a registered URI, which helps prevent some attacks. Any HTTP redirect URIs must be protected with TLS security, so the service will only redirect to URIs beginning with "https". This prevents tokens from being intercepted during the authorization process. Native apps may register a redirect URI with a custom URL scheme for the application, which may look like demoapp://redirect.

    Client ID and Secret

    After registering your app, you will receive a client ID and a client secret. The client ID is considered public information, and is used to build login URLs, or included in Javascript source code on a page. The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as single-page Javascript apps or native apps, then the secret is not used, and ideally the service shouldn't issue a secret to these types of apps in the first place.

    Authorization

    The first step of OAuth 2 is to get authorization from the user. For browser-based or mobile apps, this is usually accomplished by displaying an interface provided by the service to the user.

    OAuth 2 provides several "grant types" for different use cases. The grant types defined are:

    • Authorization Code for apps running on a web server, browser-based and mobile apps
    • Password for logging in with a username and password
    • Client credentials for application access
    • Implicit was previously recommended for clients without a secret, but has been superceded by using the Authorization Code grant with no secret.

    Each use case is described in detail below.

    Web Server Apps

    Web server apps are the most common type of application you encounter when dealing with OAuth servers. Web apps are written in a server-side language and run on a server where the source code of the application is not available to the public. This means the application is able to use its client secret when communicating with the authorization server, which can help avoid some attack vectors.

    Authorization

    Create a "Log In" link sending the user to:

    https://oauth2server.com/auth?response_type=code&
      client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx
    • code - Indicates that your server expects to receive an authorization code
    • client_id - The client ID you received when you first created the application
    • redirect_uri - Indicates the URI to return the user to after authorization is complete
    • scope - One or more scope values indicating which parts of the user's account you wish to access
    • state - A random string generated by your application, which you'll verify later

    The user sees the authorization prompt

    OAuth Authorization Prompt

    If the user clicks "Allow," the service redirects the user back to your site with an auth code

    https://oauth2client.com/cb?code=AUTH_CODE_HERE&state=1234zyx
    • code - The server returns the authorization code in the query string
    • state - The server returns the same state value that you passed

    You should first compare this state value to ensure it matches the one you started with. You can typically store the state value in a cookie or session, and compare it when the user comes back. This ensures your redirection endpoint isn't able to be tricked into attempting to exchange arbitrary authorization codes.

    Token Exchange

    Your server exchanges the auth code for an access token:

    POST https://api.oauth2server.com/token
      grant_type=authorization_code&
      code=AUTH_CODE_HERE&
      redirect_uri=REDIRECT_URI&
      client_id=CLIENT_ID&
      client_secret=CLIENT_SECRET
    • grant_type=authorization_code - The grant type for this flow is authorization_code
    • code=AUTH_CODE_HERE - This is the code you received in the query string
    • redirect_uri=REDIRECT_URI - Must be identical to the redirect URI provided in the original link
    • client_id=CLIENT_ID - The client ID you received when you first created the application
    • client_secret=CLIENT_SECRET - Since this request is made from server-side code, the secret is included

    The server replies with an access token and expiration time

    {
      "access_token":"RsT5OjbzRn430zqMLgV3Ia",
      "expires_in":3600
    }

    or if there was an error

    {
      "error":"invalid_request"
    }

    Security: Note that the service must require apps to pre-register their redirect URIs.

    Single-Page Apps

    Single-page apps (or browser-based apps) run entirely in the browser after loading the source code from a web page. Since the entire source code is available to the browser, they cannot maintain the confidentiality of their client secret, so the secret is not used in this case. The flow is exactly the same as the authorization code flow above, but at the last step, the authorization code is exchanged for an access token without using the client secret.

    Note: Previously, it was recommended that browser-based apps use the "Implicit" flow, which returns an access token immediately and does not have a token exchange step. In the time since the spec was originally written, the industry best practice has changed to recommend that the authorization code flow be used without the client secret. This provides more opportunities to create a secure flow, such as using the state parameter. References: Redhat, Deutsche Telekom, Smart Health IT.

    Authorization

    Create a "Log In" link sending the user to:

    https://oauth2server.com/auth?response_type=code&
      client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx
    • code - Indicates that your server expects to receive an authorization code
    • client_id - The client ID you received when you first created the application
    • redirect_uri - Indicates the URI to return the user to after authorization is complete
    • scope - One or more scope values indicating which parts of the user's account you wish to access
    • state - A random string generated by your application, which you'll verify later

    The user sees the authorization prompt

    OAuth Authorization Prompt

    If the user clicks "Allow," the service redirects the user back to your site with an auth code

    https://oauth2client.com/cb?code=AUTH_CODE_HERE&state=1234zyx
    • code - The server returns the authorization code in the query string
    • state - The server returns the same state value that you passed

    You should first compare this state value to ensure it matches the one you started with. You can typically store the state value in a cookie, and compare it when the user comes back. This ensures your redirection endpoint isn't able to be tricked into attempting to exchange arbitrary authorization codes.

    Token Exchange

    POST https://api.oauth2server.com/token
      grant_type=authorization_code&
      code=AUTH_CODE_HERE&
      redirect_uri=REDIRECT_URI&
      client_id=CLIENT_ID
    • grant_type=authorization_code - The grant type for this flow is authorization_code
    • code=AUTH_CODE_HERE - This is the code you received in the query string
    • redirect_uri=REDIRECT_URI - Must be identical to the redirect URI provided in the original link
    • client_id=CLIENT_ID - The client ID you received when you first created the application

    Mobile Apps

    Note: Previously, it was recommended that mobile and native apps use the Implicit grant. In the time since the spec was originally written, the industry best practice has changed to recommend using the authorization code flow with no secret for native apps. There are some additional recommendations for native apps that is worth reading as well.

    Like browser-based apps, mobile apps also cannot maintain the confidentiality of their client secret. Because of this, mobile apps must also use an OAuth flow that does not require a client secret. There are some additional concerns that mobile apps should keep in mind to ensure the security of the OAuth flow.

    Authorization

    Create a "Log in" button sending the user to either the native app of the service on the phone, or a mobile web page for the service. On iPhone, apps can register a custom URI protocol such as "facebook://" so the native Facebook app is launched whenever a URL with that protocol is visited. On Android, apps can register URL matching patterns which will launch the native app if a URL matching the pattern is visited.

    Using the Service's Native App

    If the user has the native Facebook app installed, direct them to the following URL:

    fbauth2://authorize?response_type=code&client_id=CLIENT_ID
      &redirect_uri=REDIRECT_URI&scope=email&state=1234zyx
    • response_type=code - indicates that your server expects to receive an authorization code
    • client_id=CLIENT_ID - The client ID you received when you first created the application
    • redirect_uri=REDIRECT_URI - Indicates the URI to return the user to after authorization is complete, such as fb00000000://authorize
    • scope=email - One or more scope values indicating which parts of the user's account you wish to access
    • state=1234zyx - A random string generated by your application, which you'll verify later

    For servers that support the PKCE extension (and if you're building a server, you should support the PKCE extension), you'll also include the following parameters. First, create a "code verifier" which is a random string that the app stores locally.

    • code_challenge=XXXXXXX - This is a base64-encoded version of the sha256 hash of the code verifier string
    • code_challenge_method=S256 - Indicates the hashing method used to compute the challenge, in this case, sha256.

    Note that your redirect URI will probably look like fb00000000://authorize where the protocol is a custom URL scheme that your app has registered with the OS.

    Using a Web Browser

    If the service does not have a native application, you can launch a mobile browser to the standard web authorization URL. Note that you should never use an embedded web view in your own application, as this provides the user no guarantee that they are actually are entering their password in the service's website rather than a phishing site.

    You should either launch the native mobile browser, or use the new iOS "SafariViewController" to launch an embedded browser in your application. This API was added in iOS 9, and provides a mechanism to launch a browser inside the application that both shows the address bar so the user can confirm they're on the correct website, and also shares cookies with the real Safari browser. It also prevents the application from inspecting and modifying the contents of the browser, so can be considered secure.

    https://facebook.com/dialog/oauth?response_type=code&client_id=CLIENT_ID
      &redirect_uri=REDIRECT_URI&scope=email&state=1234zyx

    Again, if the service supports PKCE, then those parameters should be included as well as described above.

    • response_type=code - indicates that your server expects to receive an authorization code
    • client_id=CLIENT_ID - The client ID you received when you first created the application
    • redirect_uri=REDIRECT_URI - Indicates the URI to return the user to after authorization is complete, such as fb00000000://authorize
    • scope=email - One or more scope values indicating which parts of the user's account you wish to access
    • state=1234zyx - A random string generated by your application, which you'll verify later

    The user will see the authorization prompt

    Facebook Authorization Prompt

    Token Exchange

    After clicking "Approve", the user will be redirected back to your application with a URL like

    fb00000000://authorize#code=AUTHORIZATION_CODE&state=1234zyx

    Your mobile application should first verify that the state corresponds to the state that was used in the initial request, and can then exchange the authorization code for an access token.

    The token exchange will look the same as exchanging the code in the web server app case, except that the secret is not sent. If the server supports PKCE, then you will need to include an additional parameter as described below.

    POST https://api.oauth2server.com/token
      grant_type=authorization_code&
      code=AUTH_CODE_HERE&
      redirect_uri=REDIRECT_URI&
      client_id=CLIENT_ID&
      code_verifier=VERIFIER_STRING
    • grant_type=authorization_code - The grant type for this flow is authorization_code
    • code=AUTH_CODE_HERE - This is the code you received in the query string
    • redirect_uri=REDIRECT_URI - Must be identical to the redirect URI provided in the original link
    • client_id=CLIENT_ID - The client ID you received when you first created the application
    • code_verifier=VERIFIER_STRING - The plaintext string that you previously hashed to create the code_challenge

    The authorization server will verify this request and return an access token.

    If the server supports PKCE, then the authorization server will recognize that this code was generated with a code challenge, and will hash the provided plaintext and confirm that the hashed version corresponds with the hashed string that was sent in the initial authorization request. This ensures the security of using the authorization code flow with clients that don't support a secret.

    Other Grant Types

    Password

    OAuth 2 also provides a "password" grant type which can be used to exchange a username and password for an access token directly. Since this obviously requires the application to collect the user's password, it must only be used by apps created by the service itself. For example, the native Twitter app could use this grant type to log in on mobile or desktop apps.

    To use the password grant type, simply make a POST request like the following:

    POST https://api.oauth2server.com/token
      grant_type=password&
      username=USERNAME&
      password=PASSWORD&
      client_id=CLIENT_ID
    • grant_type=password - The grant type for this flow is password
    • username=USERNAME - The user's username as collected by the application
    • password=PASSWORD - The user's password as collected by the application
    • client_id=CLIENT_ID - The client ID you received when you first created the application

    The server replies with an access token in the same format as the other grant types.

    Note, the client secret is not included here under the assumption that most of the use cases for password grants will be mobile or desktop apps, where the secret cannot be protected.

    Application access

    In some cases, applications may need an access token to act on behalf of themselves rather than a user. For example, the service may provide a way for the application to update their own information such as their website URL or icon, or they may wish to get statistics about the users of the app. In this case, applications need a way to get an access token for their own account, outside the context of any specific user. OAuth provides the client_credentials grant type for this purpose.

    To use the client credentials grant type, make a POST request like the following:

    POST https://api.oauth2server.com/token
        grant_type=client_credentials&
        client_id=CLIENT_ID&
        client_secret=CLIENT_SECRET

    The response will include an access token in the same format as the other grant types.

    Making Authenticated Requests

    The end result of all the grant types is obtaining an access token.

    Now that you have an access token, you can make requests to the API. You can quickly make an API request using cURL as follows:

    curl -H "Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia" \
    https://api.oauth2server.com/1/me
    

    That's it! Make sure you always send requests over HTTPS and never ignore invalid certificates. HTTPS is the only thing protecting requests from being intercepted or modified.

    Differences from OAuth 1.0

    OAuth 1.0 was largely based on existing proprietary protocols such as Flickr's "FlickrAuth" and Google's "AuthSub". The result represented the best solution based on actual implementation experience. However, after several years of working with the protocol, the community learned enough to rethink and improve the protocol in three main areas where OAuth 1.0 proved limited or confusing:

    Authentication and Signatures

    The majority of developers' confusion and annoyance with OAuth 1.0 was due to the cryptographic requirements of signing requests with the client ID and secret. Losing the ability to easily copy and paste cURL examples made it much more difficult to get started quickly.

    OAuth 2 recognizes this difficulty and replaces signatures with requiring HTTPS for all communications between browsers, clients and the API.

    User Experience and Alternative Authorization Flows

    OAuth includes two main parts, obtaining an access token, and using the access token to make requests. OAuth 1.0 works best for desktop web browsers, but fails to provide a good user experience for native desktop and mobile apps or alternative devices such as game or TV consoles.

    OAuth 2 supports a better user experience for native applications, and supports extending the protocol to provide compatibility with future device requirements.

    Performance at Scale

    As larger providers started to use OAuth 1.0, the community quickly realized the protocol does not scale well. Many steps require state management and temporary credentials, which require shared storage and are difficult to synchronize across data centers. OAuth 1.0 also requires that the API server has access to the application's ID and secret, which often breaks the architecture of most large providers where the authorization server and API servers are completely separate.

    OAuth 2 supports the separation of the roles of obtaining user authorization and handling API calls. Larger providers needing this scalability are free to implement it as such, and smaller providers can use the same server for both roles if they wish.

    Resources

    • Learn more about creating OAuth 2.0 Servers
    • PKCE Extension
    • Recommendations for Native Apps
    • More information is available on OAuth.net
    • Some content adapted from hueniverse.com.
    💵 Tip Jar 🍻

    Previous versions of this post:

    • July 2012

    OAuth Consultation

    Aaron Parecki is available to provide OAuth training and consultation for you and your team. A typical consultation will involve a half-day or full-day session, starting with an introduction to OAuth 2.0 tailored to your needs, followed by spending time addressing the specific questions of your team relating to your product. Please email me at aaron@parecki.com for my availability.

    permalink
    6 replies 107 mentions
    • Avdi Grimm avdi.org
      As guides to OAuth go, this one doesn't suck pocket.co/sckvF
      Sun, Jun 8, 2014 5:38pm +00:00 (via brid-gy.appspot.com)
    • David Montesdeoca twitter.com/backpackerhh
      #OAuth 2 Simplified: aaronparecki.com/articles/2012/…
      Sun, Jun 8, 2014 5:46pm +00:00 (via brid-gy.appspot.com)
    • channa ly www.channaly.info
      @aaronpk yes sure. it is really helpful thanks for sharing that.
      Wed, Sep 3, 2014 4:34pm +00:00 (via brid-gy.appspot.com)
    • Aaron Parecki aaronparecki.com
      @luxagraf OAuth 2 is simple enough you don't need a library, I have a simple guide here https://aaronparecki.com/2012/07/29/2/oauth2-simplified
      Mon, Jul 11, 2016 12:17pm -07:00
    • Scott Gilbertson luxagraf.net
      @aaronpk It's simple enough if someone is around for redirects and auth codes, harder when it's an automated script.
      Mon, Jul 11, 2016 7:28pm +00:00 (via brid-gy.appspot.com)
    • Aaron Parecki aaronparecki.com
      @luxagraf Yeah, you'll want to set up a page that can generate an access token for you. Some services like GitHub provide this built in.
      Mon, Jul 11, 2016 7:31pm +00:00 (via brid-gy.appspot.com)

    Other Mentions

    • medium.com
      Tue, Jun 6, 2017 12:07pm -08:00
    • stackoverflow.com
      Thu, Feb 18, 2016 12:06pm -08:00
    • medium.com
      Tue, Apr 25, 2017 8:32am -08:00
    • medium.com
      Wed, May 24, 2017 6:30am -08:00
    • medium.com
      Wed, May 24, 2017 6:31am -08:00
    • stackoverflow.com
      Mon, Feb 22, 2016 12:30am -08:00
    • medium.com
      Thu, Jun 1, 2017 12:20pm -08:00
    • www.sitepoint.com
      Fri, Apr 15, 2016 5:32am -08:00
    • medium.com
      Wed, May 24, 2017 4:18pm -08:00
    • www.treeserviceloganut.com
      Thu, Apr 27, 2017 8:38pm -08:00
    • hackernoon.com
      Mon, Mar 20, 2017 11:24am -08:00
    • stackoverflow.com
      Wed, Jan 18, 2017 2:25am -08:00
    • stackoverflow.com
      Thu, May 12, 2016 9:18am -08:00
    • 4gophers.ru
      Fri, Jun 24, 2016 1:54pm -08:00
    • twitter.com
      Wed, Feb 8, 2017 5:29am -08:00
    • www.sdk.cn
      Mon, Apr 18, 2016 7:04pm -08:00
    • nicksnettravels.builttoroam.com
      Sat, Jan 21, 2017 10:33pm -08:00
    • stackoverflow.com
      Fri, Mar 24, 2017 5:52am -08:00
    • stackoverflow.com
      Sun, Oct 2, 2016 9:47am -08:00
    • stackoverflow.com
      Tue, Oct 4, 2016 2:30pm -08:00
    • security.stackexchange.com
      Tue, Jun 14, 2016 11:11pm -08:00
    • stackoverflow.com
      Wed, Jul 20, 2016 6:52pm -08:00
    • blog.gopheracademy.com
      Fri, Oct 14, 2016 9:32pm -08:00
    • Aaron Parecki aaronparecki.com
      OAuth 2 Simplified
      Sun, Jul 29, 2012 9:30am -07:00
    • Aaron Parecki aaronparecki.com
      OAuth 2 Simplified
      Sun, Jul 29, 2012 9:30am -07:00
    • Posted by cristanmeijer blogmobile.itude.com/author/cristanmeijer
      Checklist for building an API Apr 8 Posted by cristanmeijer ...
      Tue, Apr 8, 2014 12:29am -08:00
    • chenlu4.sinaapp.com
      Programming an OAuth2 Client App in PHP 参考:http://20missionglass.tumblr.com/post/60787835108/programming-an-oauth2-client-app-in-php OAuth2 Simplified: http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified ...
      Wed, May 7, 2014 2:57am -08:00
    • www.kaleidos.net
      Stateless Authentication with api rest
      Tue, Jun 17, 2014 6:32am -08:00
    • Aaron Parecki aaronparecki.com
      @rob_levine I'm curious what your current issues are! Would love to make sure it's addressed in the book. Also check out my basic OAuth 2.0 tutorial here if you haven't yet http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified
      Wed, Jun 25, 2014 1:37pm -07:00
    • mesotheliomacare.xyz
      Oauth Introduction
      Fri, Jun 27, 2014 1:05pm +00:00
    • www.zescience.com
      As an Oauth2 service provider, how do I validate which app is passing me the user token?
      Wed, Jul 30, 2014 9:51am -08:00
    • www.pearltrees.com
      Wed, Aug 20, 2014 7:37am -08:00
    • Aaron Parecki aaronparecki.com
      @channaly Thanks! You might also like my written version of the talk: http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified #oauth2
      Wed, Sep 3, 2014 9:31am -07:00
    • doanswers.biz
      @fontface not operative on server though on localhost
      Mon, Sep 8, 2014 11:07am -08:00
    • curiouser.cheshireeng.com
      Digression: Using OAuth 2.0 at WordPress.com 10 Wednesday ...
      Wed, Sep 10, 2014 10:19am -08:00
    • ziesman.ld-gyan.biz
      ASP.NET MVC – Forms Auth vs OAuth 2.0
      Wed, Sep 10, 2014 8:59pm -08:00
    • mintknow.biz
      oAuth2 server. Should we have unparalleled or opposite endpoints for opposite extend type
      Fri, Sep 12, 2014 12:51pm -08:00
    • inhumanbean.com
      OAuth 2 Simplified – Aaron Parecki
      Tue, Nov 11, 2014 8:34am -08:00
    • raymondhlee.wordpress.com
      Implementing OAuth2 with Spring Security December 21, 2014 Leave a comment ...
      Sat, Dec 20, 2014 7:10pm -08:00
    • www.quora.com
      Fri, Feb 6, 2015 8:30am -08:00
    • www.noblebuffalo.com
      Portico API
      Mon, Mar 2, 2015 9:51am -08:00
    • dluat.com
      Session integration, is this approach secure?
      Sun, Apr 19, 2015 10:31pm -08:00
    • freemymind.wordpress.com
      OAuth 2.0 for Native Mobile Apps and Browser Apps
      Wed, Apr 29, 2015 9:16am -08:00
    • 7wins.eu
      Wed, Apr 29, 2015 10:23pm -08:00
    • nodejs.clbo.dk
      #10 Authendication / Authorization
      Sun, May 3, 2015 11:50pm +00:00
    • onehundred15.wordpress.com
      Fri, Jun 19, 2015 8:26pm -08:00
    • dexpage.com
      Thu, Jun 25, 2015 8:47am -08:00
    • dexpage.com
      Fri, Jul 3, 2015 2:03am -08:00
    • dexpage.com
      Wed, Jul 8, 2015 4:06pm -08:00
    • dexpage.com
      Wed, Jul 8, 2015 6:03pm -08:00
    • unity3dassets.com
      Mon, Jul 13, 2015 3:15pm -08:00
    • dexpage.com
      Wed, Jul 15, 2015 1:19pm -08:00
    • fewfice.com
      Wed, Aug 26, 2015 12:58am -08:00
    • blog.explodingads.com
      1 – Oauth2 simplifiedBy blog.explodingads.com on August 28, 2015 in Startups By pietromenna 1 point, 0 comments ...
      Fri, Aug 28, 2015 4:37pm +00:00
    • emoo www.emoo.eu/author/emoo
      How authorization works with APIs
      Sat, Sep 5, 2015 8:26am -08:00
    • Tiffany Lien www.linkedin.com/in/tiffanylien
      The most straight-forward description of OAuth: ow.ly/Sfo6i #tech
      Tue, Sep 15, 2015 6:50pm +00:00 (via brid-gy.appspot.com)
    • Joshua Ellis www.jellis.com.au
      The most simplistic #oauth2 explanation I've seen by @aaronpk aaronparecki.com/articles/2012/… Awesome job.
      Wed, Sep 23, 2015 10:11am +00:00 (via brid-gy.appspot.com)
    • れこ leko.jp
      読了 OAuth 2 Simplified ift.tt/1FqFICu ift.tt/1Ffge0c
      Wed, Sep 23, 2015 2:50pm +00:00 (via brid-gy.appspot.com)
    • Amir S twitter.com/momenticus
      Brief and straight forward explanation of oauth-2: aaronparecki.com/articles/2012/…
      Thu, Oct 15, 2015 9:58pm +00:00 (via brid-gy.appspot.com)
    • Alex Maldonado twitter.com/OOCoder
      Excellent explanation of Oauth2 protocol and the flow details. A better job than Google/Facebook IMHO :). @aaronpk buff.ly/1MubTVV
      Tue, Oct 27, 2015 9:39pm +00:00 (via brid-gy.appspot.com)
    • Oleg Dulin cdn.wikinewstech.com/author/oleg-dulin
      IDG Contributor Network: OAuth 2.0: The protocol at the center of the universe
      Tue, Nov 24, 2015 9:23am -08:00
    • Oleg Dulin cdn.wikinewstech.com/author/oleg-dulin
      IDG Contributor Network: OAuth 2.0: The protocol at the center of the universe
      Wed, Nov 25, 2015 1:23am -08:00
    • Oleg Dulin cdn.wikinewstech.com/author/oleg-dulin
      IDG Contributor Network: OAuth 2.0: The protocol at the center of the universe
      Wed, Nov 25, 2015 2:17am -08:00
    • questions.techjaffa.info
      As an Oauth2 service provider, how do I validate which app is passing me the user token?
      Thu, Nov 26, 2015 5:33am -08:00
    • questions.techjaffa.info
      How do I implement an OAuth2 Authorization_Code Flow in Web Api using OWIN Middleware?
      Thu, Nov 26, 2015 2:17pm -08:00
    • M@ matthew-sinclair.com
      “OAuth 2 Simplified” bit.ly/1LGJU2h #bookmarked
      Sun, Nov 29, 2015 4:21pm +00:00 (via brid-gy.appspot.com)
    • literally an egg yoshuawuyts.com
      If you want to know more about OAuth, this is probably the article you're looking for - aaronparecki.com/articles/2012/…
      Wed, Dec 16, 2015 1:22am +00:00 (via brid-gy.appspot.com)
    • Hernan Marano about.me/herchugm
      Finally, an introduction to #oauth that can be understood aaronparecki.com/articles/2012/… by @aaronpk
      Thu, Dec 17, 2015 5:22pm +00:00 (via brid-gy.appspot.com)
    • Nicolas Grancher www.pbunk.com
      OAuth 2 Simplified - aaronparecki.com/articles/2012/…
      Mon, Dec 21, 2015 7:17am +00:00 (via brid-gy.appspot.com)
    • Nicolas Grancher www.pbunk.com
      OAuth 2 Simplified - aaronparecki.com/articles/2012/…
      Mon, Dec 21, 2015 7:17am +00:00 (via brid-gy.appspot.com)
    • by Oleg Dulin www.wikinewstech.com/us/author/oleg-dulin
      IDG Contributor Community: OAuth 2.zero: The protocol on the middle of the universe
      Tue, Dec 22, 2015 8:11am -08:00
    • by Oleg Dulin www.wikinewstech.com/us/author/oleg-dulin
      IDG Contributor Community: OAuth 2.zero: The protocol on the middle of the universe
      Tue, Dec 22, 2015 6:42pm -08:00
    • by Oleg Dulin www.wikinewstech.com/us/author/oleg-dulin
      IDG Contributor Community: OAuth 2.zero: The protocol on the middle of the universe
      Wed, Dec 23, 2015 3:38am -08:00
    • Tuan Nguyen blog.tuannguyena.com
      OAuth 2 Simplified - Aaron Parecki aaronparecki.com/articles/2012/…
      Tue, Dec 29, 2015 2:36am +00:00 (via brid-gy.appspot.com)
    • admin php.javacss.space/author/admin
      Unable to get JSON response from cURL when hitting url https://api.instagram.com/oauth/authorize/?client_id=&redirect_uri=http://localhost/instagram_flow/result.php&response_type=code&scope=basic+comments+relationships+likes in browser response as: {“code”: 400, “error_type”: “oauthexception”, “error_message”: “you must include valid client_id, response_type, , redirect_uri parameters”} ...
      Mon, Jan 11, 2016 6:48pm +00:00
    • Ryan Wilson-Perkin ryanwilsonperkin.com
      Your simplified article on OAuth2 was incredibly easy to understand, thanks for writing it!aaronparecki.com/articles/2012/…
      Wed, Jan 13, 2016 9:11pm +00:00 (via brid-gy.appspot.com)
    • Ryan Wilson-Perkin ryanwilsonperkin.com
      @aaronpk Your simplified article on OAuth2 was the first I found easy to understand, thanks for writing it! aaronparecki.com/articles/2012/…
      Wed, Jan 13, 2016 9:13pm +00:00 (via brid-gy.appspot.com)
    • Aaron Parecki aaronparecki.com
      @rwilsonperkin Thanks! Glad you found it useful!
      Wed, Jan 13, 2016 9:14pm +00:00 (via brid-gy.appspot.com)
    • cssphp.space/author
      Client secret for Django oauth – i using django oauth toolkit , django rest oauth authentication mobile app. accessing protected resource client id , secret of app required . should store client secret. storing in apk unsafe can decompiled. obfuscation can reverse engineered . whats best , safe way serve client secret app. it isn’t extremely of import maintain client id hidden, right not save client secret somewhere in app. exposing compromise security. ...
      Wed, Jan 13, 2016 10:19pm +00:00
    • Martin twitter.com/mm001bask
      aaronparecki.com/articles/2012/…
      Sat, Jan 30, 2016 12:44pm +00:00 (via brid-gy.appspot.com)
    • Marcin Gryszko grysz.com
      OAuth2 Simplified, Aaron Parecki buff.ly/1pEYXXF
      Tue, Mar 22, 2016 10:10am +00:00 (via brid-gy.appspot.com)
    • Robin Chalas github.com/chalasr
      #OAuth2 Simplified (As much as it can be) aaronparecki.com/2012/07/29/2/o…
      Wed, Apr 6, 2016 11:08pm +00:00 (via brid-gy.appspot.com)
    • dan mcweeney blog.danmcweeney.com
      Nice rundown on the spec. Good primer reference. aaronparecki.com/2012/07/29/2/o…
      Sun, May 29, 2016 11:20pm +00:00 (via brid-gy.appspot.com)
    • Luis Angel Lopez twitter.com/lopezchairez
      @aaronpk finally understood when to use an #oauth2 server #php #laravel #laracasts goo.gl/n4bebM
      Thu, Jun 30, 2016 8:02pm +00:00 (via brid-gy.appspot.com)
    • Adam Chalmers adamchalmers.github.io
      This is the best OAuth2 explainer I've found: aaronparecki.com/2012/07/29/2/o…
      Fri, Jul 15, 2016 2:18am +00:00 (via brid-gy.appspot.com)
    • ISRA twitter.com/IsraMtinajero
      OAuth 2 Simplifiedaaronparecki.com/2012/07/29/2/o…
      Wed, Jul 27, 2016 4:49pm +00:00 (via brid-gy.appspot.com)
    • Sec News Bot twitter.com/SecNewsBot
      Hacker News - OAuth 2 Simplified (2012) ift.tt/24TC4Qk
      Wed, Jul 27, 2016 10:13pm +00:00 (via brid-gy.appspot.com)
    • Klaus Peter Laube www.klauslaube.com.br
      OAuth 2 Simplified aaronparecki.com/2012/07/29/2/o…
      Thu, Aug 18, 2016 6:51pm +00:00 (via brid-gy.appspot.com)
    • Ilker Temir www.linkedin.com/in/ilkertemir
      Confused by #oauth2? Read @aaronpk's "OAuth 2 Simplified", confusion will evaporate quickly. aaronparecki.com/2012/07/29/2/o…
      Mon, Aug 22, 2016 1:37am +00:00 (via brid-gy.appspot.com)
    • Juan soundcloud.com/elxavit0/sets
      Revisiting this really nice writeup on OAuth2 --> aaronparecki.com/articles/2012/… #oauth #oauth2 #standards #web #authentication
      Tue, Aug 23, 2016 1:51pm +00:00 (via brid-gy.appspot.com)
    • willemodendaal medium.com/the-curious-coder
      A nice simple explanation of oath2 scenarios: aaronparecki.com/2012/07/29/2/o…
      Thu, Aug 25, 2016 6:27am +00:00 (via brid-gy.appspot.com)
    • Florent Dupont florent-dupont.blogspot.fr
      Oauth2 simplified aaronparecki.com/2012/07/29/2/o…
      Mon, Sep 26, 2016 8:31pm +00:00 (via brid-gy.appspot.com)
    • danvitoriano www.fullcircle.com.br
      OAuth 2 Simplified • Aaron Parecki aaronparecki.com/2012/07/29/2/o…
      Thu, Nov 3, 2016 1:14pm +00:00 (via brid-gy.appspot.com)
    • Tom Kadwill kadwill.com
      A simplified guide to OAuth2 aaronparecki.com/2012/07/29/2/o…
      Mon, Dec 12, 2016 8:07pm +00:00 (via brid-gy.appspot.com)
    • Klaus Peter Laube www.klauslaube.com.br
      Já devo ter compartilhado esse link, mas é tão bom que vai de novo: aaronparecki.com/2012/07/29/2/o… #oauth2
      Thu, Dec 15, 2016 4:32pm +00:00 (via brid-gy.appspot.com)
    • Punit Narang twitter.com/mepunit
      OAuth 2 Simplified • Aaron Parecki aaronparecki.com/2012/07/29/2/o…
      Mon, Jan 2, 2017 7:57pm +00:00 (via brid-gy.appspot.com)
    • Sanjeya C twitter.com/sanjeyac
      An awesome simplified OAuth 2.0 explanation by @aaronpk aaronparecki.com/oauth-2-simpli… #web #security #development
      Sun, Jan 29, 2017 1:49pm +00:00 (via brid-gy.appspot.com)
    • Carlos Becerra charz4travel.blogspot.com.es
      OAuth 2 Simplified aaronparecki.com/oauth-2-simpli…
      Wed, Feb 15, 2017 2:44pm +00:00 (via brid-gy.appspot.com)
    • Jafeth Díaz twitter.com/jafethdc
      What is OAuth2? aaronparecki.com/oauth-2-simpli…
      Thu, Mar 2, 2017 10:17pm +00:00 (via brid-gy.appspot.com)
    • James Schmidt jamesdschmidt.com
      OAuth 2 Simplified #oauth2 #security aaronparecki.com/oauth-2-simpli…
      Sun, Mar 12, 2017 3:54am +00:00 (via brid-gy.appspot.com)
    • Yauhen Yakimovich yauhen.yakimovich.info
      really nice explanation of oauth2 aaronparecki.com/oauth-2-simpli…
      Mon, Mar 27, 2017 12:26pm +00:00 (via brid-gy.appspot.com)
    • Jérôme Oudoul www.oudoul.com
      I was building a WebAPI 2 with OAuth and came upon this very informative post on the protocol "OAuth 2.0 Simplified" aaronparecki.com/oauth-2-simpli…
      Thu, Apr 6, 2017 1:09pm +00:00 (via brid-gy.appspot.com)
    • Marc Brufau Junyent twitter.com/mbrufau1978
      aaronparecki.com/oauth-2-simpli…
      Thu, Apr 20, 2017 2:26pm +00:00 (via brid-gy.appspot.com)
    • Patrick Schaller F3Development.com
      @aaronpk I was just reading your article goo.gl/IF9r2O which was helpful. Is using SafariViewController the only safe auth on iOS?
      Thu, May 4, 2017 5:11pm +00:00 (via brid-gy.appspot.com)
    • Nitish Parkar nitishparkar.com
      Finally I understand OAuth 2 a bit :) OAuth 2 Simplified - aaronparecki.com/oauth-2-simpli…
      Sun, May 7, 2017 3:44pm +00:00 (via brid-gy.appspot.com)
    • Geoffrey Giesemann twitter.com/ggiesemann
      OAuth 2 (just the SSO bits) aaronparecki.com/oauth-2-simpli…
      Mon, May 8, 2017 6:07pm +00:00 (via brid-gy.appspot.com)
    • Maximillian twitter.com/maximillian2012
      OAuth 2 Simplifiedaaronparecki.com/oauth-2-simpli…
      Wed, May 10, 2017 5:56pm +00:00 (via brid-gy.appspot.com)

Hi, I'm Aaron Parecki, co-founder of IndieWebCamp. I maintain oauth.net, write and consult about OAuth, and am the editor of the W3C Webmention and Micropub specifications, and co-editor of WebSub.

I wrote 100 songs in 100 days! I've been tracking my location since 2008, and write down everything I eat and drink. I've spoken at conferences around the world about owning your data, OAuth, quantified self, and explained why R is a vowel.

Follow
  • IndieWebCamp Founder
  • W3C Editor
  • W7APK
  • These are a few of my favorite things.
  • All
  • Articles
  • Bookmarks
  • Notes
  • Photos
  • Reviews
  • Sleep
  • Travel
  • Contact
© 1999-2017 by Aaron Parecki. Powered by p3k. This site supports Webmention.
Except where otherwise noted, text content on this site is licensed under a Creative Commons Attribution 3.0 License.