1. 红孩笔记首页
  2. 安全

OAuth 2.0 Beginner’s Guide

• 安全 • 阅读 5750

This article provides an overview of OAuth 2.0 protocol. It discusses the different actors and steps involved in the process of OAuth 2.0 implementation.

Introduction:

OAuth stands for Open Authorization. It’s a free and open protocol, built on IETF standards and licenses from the Open Web Foundation. It allows users to share their private resources with a third party while keeping their own credentials secret. These resources could be photos, videos, contact lists, location and billing capabilities, and so on, and are usually stored with another service provider. OAuth does this by granting the requesting (client) applications a token, once access is approved by the user. Each token grants limited access to a specific resource for a specific period.

1. Oauth2 Is a Delegation Protocol:

OAuth2 supports “delegated authentication,” i.e. granting access to another person or application to perform actions on your behalf. Consider this scenario: you drive your car to a classy hotel, they may offer valet parking. You then authorize the valet attendant to drive your car by handing him the key in order to let him perform actions on your behalf.

OAuth2 works similarly—a user grants access to an application to perform limited actions on the user’s behalf and access can be revoked when it become suspicious.

2. Actors Involved in OAuth2:

i) Resource Server: The server hosting user-owned resources that are protected by OAuth2. The resource server validates the access-token and serves the protected resources.

ii) Resource Owner: Typically, the user of the application is the resource owner. The resource owner has the ability to grant or deny access to their own data hosted on the resource server.

iii) Authorization Server: The authorization server gets consent from the resource owner and issues access tokens to clients for accessing protected resources hosted by a resource server.

iv) Client: An application making API requests to perform actions on protected resources on behalf of the resource owner. Before it may do so, it must be authorized by the resource owner, and the authorization must be validated by resource server/authorization server. OAuth2 defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):

a)Confidential: Clients capable of maintaining the confidentiality of their credentials. Confidential clients are implemented on a secure server with restricted access to the client credentials (e.g., a web application running on a web server).

b) Public: Clients incapable of maintaining the confidentiality of their credentials (e.g. an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

3. You Are an Application Developer, Here Is a Use Case:

Consider a scenario. You are developing a fun Facebook app, and you call it “FunApp.” FunApp needs access to the user’s public profile, photos, posts, friends, etc. Now the problem is, how can FunApp get the user’s permission to access his/her data from Facebook, while simultaneously informing Facebook that the user has granted this permission to FunApp so that Facebook will share the user’s data with this app?

The old way: the user shares his/her facebook credentials (username, password) with FunApp. This approach has some challenges: trust, unrestricted access, changes to the Facebook password made by the user, etc.

The OAuth2 way: Funapp would redirect users to an authorization page on Facebook if the app needed access to their user data. Users would log in to their accounts and grant access, and then FunApp would get an access token from Facebook to access the user’s data. While Oauth2 has solved these challenges, it also created costs for developers. 

Let’s see this scenario from developer’s eyes and find out the actors involved here:

  • Since Facebook has all the resources (user’s public profile, photos, posts, friends, etc.), it becomes the resource server.

  • The user is the resource owner.

  • When FunApp requests the user’s protected resources, it becomes the client.

  • When Facebook gets the user’s consent and issues the access token to FunApp, it becomes the authorization server.

4. Register Client (FunApp) and Get Client Credentials:

OAuth requires that the client registers with the authorization server. The authorization server asks for some basic information about the client such as name, redirect_uri (the URL where the authorization server will redirect to when the resource owner grants permission) and returns client credentials (client-id, client-secret) to the client. These credentials are critical in protecting the authenticity of requests when performing operations such as exchanging authorization codes for access tokens and refreshing access tokens.

For example, Facebook requires you to register your client on the Facebook Developers portal. Go to Facebook developers portal and register FunApp and get client credentials.

5. Get an Access Token Step-by-Step:

FunApp needs to get an access token from Facebook to access the user’s data. In order to get an access token, FunApp redirects the user to Facebook’s login page. Upon successful login, Facebook redirects to the redirect_uri (as registered in step 4) along with the short-lived authorization code. FunApp exchanges the authorization code to get the long-lived access token. The access token is used to access the user’s data. This is the most popular flow in OAuth2, called authorization code grant. Here is the sequence diagram to get an access token in the authorization code grant:

Steps to get access token in Authorization code grant

6. Understanding Authorization Grant Types:

To get the access token, the client obtains authorization from the resource owner. The authorization is expressed in the form of an authorization grant, which the client uses to request the access token. OAuth2 defines four standard grant types: authorization code, implicit, resource owner password credentials, and client credentials. It also provides an extension mechanism for defining additional grant types.

i) Authorization Code Grant: this grant type is optimized for confidential clients (web application server). The authorization code flow does not expose the access token to the resource owner’s browser. Instead, authorization is accomplished using an intermediary “authorization code” that is passed through the browser. This code must be exchanged for an access token before calls can be made to protected APIs.

ii) Implicit Grant: this grant type is suitable for public clients. The implicit grant flow does not accommodate refresh tokens. If the authorization server expires access tokens regularly, your application will need to run through the authorization flow whenever it needs access. In this flow, an access token is immediately returned to the client after a user grants the requested authorization. An intermediate authorization code is not required as it is in the authorization code grant.

iii) Resource Owner Password Credentials: the resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, and the resource owner agrees to share hise/her credentials (username, password) with the client. Then the client can use resources from the owner’s credentials to get the access token from the authorization server.

iv) Client Credentials: this grant type is suitable when the client itself owns the data and does not need delegated access from a resource owner, or delegated access has already been granted to the application outside of a typical OAuth flow. In this flow, user consent is not involved. The client exchanges his client credentials to get an access token.

7. Token Expired, Get a New Access Token: 

Making API calls using the OAuth 2.0 access token may encounter errors if the access token is no longer valid because the token expired or was revoked. In this case, the resource server will return a 4xx error code. The client can get the new access token using the refresh token (which was obtained when the authorization code was exchanged for an access token).

8. Conclusion:

This is an attempt to provide an overview of the OAuth 2.0 process, as well as provide a way to obtain an access token. I hope it has been helpful.

Have fun integrating apps!

文章来源于互联网:OAuth 2.0 Beginner’s Guide

发布者：小站，转转请注明出处：http://blog.gzcity.top/4268.html

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
1393
上一篇 2022年5月3日 18:09
下一篇 2022年5月3日 18:09

相关推荐

  • 识别并修复 Web 应用中的 XSS 漏洞 学习笔记

    识别并修复 Web 应用中的 XSS 漏洞

    什么是跨站点脚本？ 跨站点脚本 （XSS） 是一个代码注入漏洞，当开发人员在将用户输入插入 HTML 模板之前未对用户输入进行足够好的审查时，就会在处理 HTML 的应用程序中发生该漏洞。它允许攻击者将任意 JavaScript 代码插入模板并在用户的上下文中执行它： 在上图中，开发人员未能清理“姓氏”div 的内容，这导致用户能够通过操纵其姓氏来包含恶意脚…

    2023年6月11日
    9.9K1270
  • 关于Apache log4j存在远程代码执行漏洞的预警 学习笔记

    关于Apache log4j存在远程代码执行漏洞的预警

    12月9日晚，互联网上公开了Apache log4j2的一个严重级别的远程代码执行漏洞。由于Apache log4j2某些功能存在递归解析功能，攻击者可直接构造恶意请求触发远程代码执行漏洞，而无需特殊配置。Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受此漏洞影响。鉴于该框架应用范围极广，且漏洞利…

    2022年8月3日
    841120

  • Implementing JWT Authentication on Spring Boot APIs

    Securing Restful APIs With JWTs JSON Web Tokens, commonly known as JWTs, are tokens that are used to authenticate users on applications. This technology has gained popularity over …

    安全 2022年5月3日
    95650

  • Go Application Vulnerability Cheatsheet

    Securing applications is not the easiest thing to do. An application has many components: server-side logic, client-side logic, data storage, data transportation, API, and more. Wi…

    安全 2022年5月3日
    1.8K70
  • Apache Log4J2 远程代码执行漏洞处置手册 学习笔记

    Apache Log4J2 远程代码执行漏洞处置手册

    1、漏洞概述 Apache Log4j2是一个基于Java的日志记录工具。该日志框架被大量用于业务系统开发，用来记录日志信息。此次爆发的0day漏洞触发条件为只要外部用户输入的数据会被日志记录，即可造成远程代码执行。 漏洞细节 漏洞PoC 漏洞EXP 在野利用已公开 已公开 已公开 存在 参考链接：https://issues.apache.org/jira…

    2022年8月3日
    2.2K1400

回复 onewinonedivision

您的邮箱地址不会被公开。 必填项已用 * 标注

评论列表（1,393条）