{"id":407805,"date":"2024-06-29T19:46:44","date_gmt":"2024-06-29T19:46:44","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=407805"},"modified":"-0001-11-30T00:00:00","modified_gmt":"2024-06-29T19:46:44","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=407805","title":{"rendered":"What are OAuth 2 and OpenID Connect\u00a0(OIDC)?<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

Author: Denys Zherdetskyi<\/p>\n

\"\"
<\/figcaption><\/figure>\n

Millions of users daily use features that facilitate their work with web services. The companies implement them to make their websites easy to use and safe. Good examples of those are OAuth 2 <\/strong> and OpenID Connect because <\/strong>they <\/strong>allow them to reach it.<\/p>\n

What we will cover in this\u00a0article:<\/h4>\n
    \n
  1. \n

    History of OAuth and flaws of prior methods<\/a><\/p>\n<\/li>\n

  2. \n

    OAuth 2 and OpenID Connect (OIDC), and the differences between them<\/a><\/p>\n<\/li>\n

  3. \n

    Purposes of OAuth 2 and OpenID Connect (OIDC)<\/a><\/p>\n<\/li>\n

  4. \n

    Working principles of OAuth 2 and OpenID Connect<\/a><\/p>\n<\/li>\n

  5. \n

    The practical example of OAuth 2 working principle with GitHub OAuth usage.<\/p>\n<\/li>\n<\/ol>\n

    History of OAuth and flaws of prior\u00a0methods<\/h4>\n

    Users always prefer websites full of features that would facilitate their work website. In 2004, as we know, there weren\u2019t any standards or protocols like OAuth 2 and OpenID Connect; that\u2019s why even well-known companies like Yelp implemented them as they could.<\/p>\n

    \"\"
    <\/figcaption><\/figure>\n

    This picture shows a screenshot from an old Yelp website showing us the Yelp feature \u201cto find a friend.\u201d You could say that it is cool till the time when you will see its implementation. You needed to give your email address and PASSWORD (!) to find a friend on Yelp because it would allow the service to log in as you and get emails you wrote often.\u00a0<\/p>\n

    Some of you would say that it is insane and cannot be accurate; however, it is. In 2004, most internet users didn\u2019t understand the basic rules that you should stick to in the \u201cnetwork\u201d and could give all their data only to use a cool feature. We should notice that, luckily, on Yelp, no one was deceived, and it was the only way for developers to implement this feature at that time. However, through the years, users became more educated, so no one wanted to give their data to anyone without protection. Developers that noticed this security flaw decided to create a standard that would allow users not to worry about their data protection and use such services easily; that\u2019s why the standard of authorization<\/strong> OAuth 1 was created. This standard still had some flaws, but it significantly shifted the security paradigm and allowed users to use cool features and not worry about their data. However, due to some problems of OAuth 1, like required cryptography, long-term living tokens, or complicated signatures, improved standard OAuth 2 was published in October 2012. It was created to solve all the problems of OAuth 1 and make using the OAuth standard easier and more secure.<\/p>\n

    OAuth 2 and OpenID Connect (OIDC), and the differences between\u00a0them<\/h3>\n

    As you already know, OAuth 2 is an authorization<\/strong> (!) standard. This standard\u2019s work endpoint is an access token that allows us to manipulate or get users\u2019 data.<\/p>\n

    Unlike OAuth 2, OpenID Connect (OIDC) is an authentication<\/strong> (!) standard. As you can see, the purpose of its usage differs from OAuth 2. Moreover, OpenID Connect (OIDC) is a standard built on OAuth 2. Developers of OIDC took the basics of OAuth 2 and expanded it with additional features that changed its shift on authentication<\/strong> from authorization<\/strong>.<\/p>\n

    As you read before, the main difference between these standards is the field of its usage (authentication<\/strong> or authorization<\/strong>). Some people don\u2019t distinguish between authentication and authorization, which can cause faulty use of these standards in their projects.<\/p>\n

    Authorization<\/strong> is a process that gives the right to a website to access some users\u2019 data or even change it if possible and needed.<\/p>\n

    Authentication<\/strong> is a process by which the website can ensure that you have access to be who you want to be and that you are not pretending to be someone.<\/p>\n

    Also, the significant difference is \u201cparty sides.\u201d The authorization<\/strong> is the \u201cthird party\u201d side, while authentication is the \u201cfirst party\u201d side. The difference lies in the purposes of these protocols. In authorization<\/strong>, you \u201cauthorize\u201d someone to access and manipulate your data freely. You don\u2019t participate directly in this process, so it\u2019s named the \u201cthird party\u201d side. In authentication, you prove to the website that you are someone, and it should or shouldn\u2019t allow you to access some of your data. In this process, you participate directly; that\u2019s why it\u2019s the \u201cfirst party\u201d side.<\/p>\n

    Purposes of OAuth 2 and OpenID Connect\u00a0(OIDC)<\/h4>\n

    Imagine the website, where you would be able to see the alike subscriptions on YouTube with your friend. How would you implement this service? Of course, the best way and most secure way is to implement it with help of OAuth 2. Here we don\u2019t need to know who the user are, or if he is, who he is or just pretending to be, however we need to access the user\u2019s data, so receive an access to it. As we already know, this is a protocol of authorization and its endpoint is an access token. After receiving a token, the website can access only data, that we allowed it to access, so OAuth use is a brilliant way.<\/p>\n

    Most of the time clicking the button \u201cSign In with Social Network\u201d on any website, you use OpenID Connect. If you don\u2019t need any authorization, but you need only to \u201cSign In\u201d or \u201cSign Up\u201d you use the authorization with standard OpenID Connect (OIDC).<\/p>\n

    Working principles of OAuth 2 and OpenID\u00a0Connect<\/h3>\n

    To implement OAuth 2 standard on the website, the developer needs to get a client id<\/strong> and client secret<\/strong> from the service he uses ( for example, Google, GitHub, LinkedIn, Apple, etc. ). The process of OAuth 2 work is called authorization flow.<\/p>\n

    OAuth 2 is a standard that establishes the sequence of code commands that developers should write to implement the concept.<\/p>\n

    Authorization Flow<\/strong><\/p>\n

      \n
    1. \n

      The user (Resource Owner) clicks the button \u201cLogin with\u00a0\u2026.\u201d<\/p>\n<\/li>\n

    2. \n

      Client (Developer\u2019s website) redirects the user to a login service using a special link that consists of client id<\/strong> (always), scope, redirect URI (always), and request type (most equals to \u201ccode\u201d).<\/p>\n<\/li>\n

    3. \n

      The link redirects to the login service, where the user can sign in with \u201clogin service\u201d or allow to use an already signed-in account.<\/p>\n<\/li>\n

    4. \n

      After the sign-in account confirmation with \u201clogin service\u201d (Authorization Server), it redirects the user to \u201credirect URI\u201d (specified by the developer in a link), sending generated authentication code in the response body or \u201credirect URI.\u201d<\/p>\n<\/li>\n

    5. \n

      After receiving a code, the website sends a POST request or redirects to a link, usually consisting of the client id<\/strong>, client secret<\/strong>, and authentication code.<\/p>\n<\/li>\n

    6. \n

      The developer should receive a generated access token for a particular user\u2019s account if he did all the steps correctly.<\/p>\n<\/li>\n

    7. \n

      After receiving an access token, the developer can send a POST request to \u201clogin service,\u201d which contains a header with an \u201cAuthorization\u201d field that equals the access token. Then after verification of the access token, the developer will be able to access data (for example, API or another allowed data).<\/p>\n<\/li>\n<\/ol>\n

      The practical example of OAuth 2 working principle with GitHub OAuth\u00a0usage<\/h4>\n

      Now you will see a practical example of OAuth 2 implementation with \u201clogin service\u201d as Github. To implement OAuth 2, developer should stick to rules established in paragraph below<\/a>.<\/p>\n

        \n
      1. \n

        Firstly, we need to receive\u00a0the client id<\/strong>\u00a0and\u00a0client secret<\/strong>; that’s why let’s register our app.\u00a0<\/p>\n

        \u00a0Enter\u00a0https:\/\/github.com\/settings\/developers<\/a>, log in to your GitHub account, and see a similar menu (shown below); click the «New OAuth App» button.<\/p>\n<\/li>\n<\/ol>\n

        \"Main
        Main OAuth Apps menu in GiHub<\/figcaption><\/figure>\n
          \n
        1. \n

          You’ll see the form where we register our app and enter (imaginary URL).<\/p>\n<\/li>\n<\/ol>\n