oauth0 oauth2
Access secure HTTP Services in Go
在Go中访问安全的HTTP服务
OAuth 2.0 is how a third party application accesses user data in the cloud. The spec describes it this way: “The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service..” So you need to understand it to programmatically access almost all user data now stored in various online services: Amazon, Google, GitHub, Facebook, LinkedIn, Strava, and countless others. In this article, we’ll build an OAuth 2.0 client application in Go and use it to access our user data in multiple services.
OAuth 2.0是第三方应用程序访问云中用户数据的方式。 规范以这种方式进行描述：“ OAuth 2.0授权框架使第三方应用程序可以获得对HTTP服务的有限访问权。”因此，您需要了解它，才能以编程方式访问现在存储在各种在线服务中的几乎所有用户数据：亚马逊，谷歌，GitHub，Facebook，LinkedIn，斯特拉瓦和其他无数个。 在本文中，我们将在Go中构建一个OAuth 2.0客户端应用程序，并使用它来访问多种服务中的用户数据。
The core spec, RFC 6749, is actually surprisingly readable so don’t be intimidated by the vast amounts of monospace text. Though keep in mind that the core spec is just the beginning of the journey, some parts are now dated and there have been a number of additions and clarifications over the years. In particular now, you’ll want to read the RFC 8252 spec for native apps.
核心规范RFC 6749实际上令人惊讶地可读，因此不要被大量的等宽文本吓倒。 尽管请记住，核心规范只是旅程的开始，但现在有些部分已经过时，并且这些年来已经进行了许多补充和说明。 特别是现在，您将要阅读本机应用程序的RFC 8252规范。
All committee based specs have their own jargon, so we’ll dive into that first to set the context.
所有基于委员会的规范都有自己的术语，因此我们将首先深入探讨它以设置上下文。
赠款类型 (Grant Types)
The core spec outlines five different ways of using OAuth 2.0, called “Grant Types”
核心规范概述了使用OAuth 2.0的五种不同方式，称为“授权类型”
4.1. Authorization Code Grant
4.1 。 授权码授予
4.2. Implicit Grant (now legacy, discouraged)
4.2 。 隐性补助金(现已遗留，不鼓励使用)
4.3. Resource Owner Password Credentials Grant (now legacy, discouraged)
4.3 。 资源所有者密码凭据授予(现已停用，不鼓励使用)
4.4. Client Credentials Grant
4.4 。 客户证书授予
4.5. Extension Grants
4.5 。 扩展赠款
A couple of extensions since then are now best practice:
从那时起，有几个扩展是最佳实践：
PKCE an extension to Authorization Code Grant that has become the preferred flow for all public apps
PKCE对授权码授予的扩展，已成为所有公共应用程序的首选流程
Device Code is an extension for constrained devices with no browser
设备代码是没有浏览器的受限设备的扩展
客户端类型和配置文件(Client Types and Profiles)
The core spec defines two different types of apps, confidential and public where the primary difference is simply that a public app is not able to maintain confidentiality of its credentials (client secret). Based on this, it goes on to list a few application roles:
核心规范定义了两种不同类型的应用程序，即机密应用程序和公共应用程序，主要区别仅在于公共应用程序无法维护其凭据的机密性(客户端机密)。 基于此，它继续列出了一些应用程序角色：
Web application: A confidential client running on a web server. This is the traditional server based web client accessing user data and Authorization Code Grant is the recommended flow. The Authorization Server may or may not allow Extension Grants to refresh the Access Token after it expires. The Client Credentials Grant is useful for a client to get data about itself, not associated with a specific user. In this case the client must be able to authenticate itself using only credentials it has securely stored or through some previous arrangement with the Authorization Server.
Web应用程序：在Web服务器上运行的机密客户端。 这是基于传统服务器的Web客户端访问用户数据，建议使用“授权代码授予”。 授权服务器可能会也可能不允许扩展授权在过期后刷新访问令牌。 客户端证书授予对于客户端获取有关自身的数据很有用，而不与特定用户相关联。 在这种情况下，客户端必须只能使用已安全存储的凭据或通过与授权服务器的某些先前安排来对自己进行身份验证。
User-agent-based application: A public client in which the code and credentials are downloaded from a web server. Single page apps fall in this role. The core spec recommends Implicit Flow for this role, but that has since been deprecated and now Authorization Code Grant with PKCE is recommended.
基于用户代理的应用程序：一个公共客户端，在其中从Web服务器下载代码和凭据。 单页应用程序担当此角色。 核心规范建议为此角色使用隐式流程，但是此建议已被弃用，现在建议使用带有PKCE的授权码授予。
Native application: A public client where code is installed and executed on a device, the application may or may not be secure but is assumed to be insecure. Both mobile and native apps fall in this role and again Authorization Code Grant with PKCE is recommended. For browserless or input constrained devices The Device Code flow is recommended which works conceptually similar to Authorization Code Grant but requires the user to manually enter a User Code (like a Client Secret) at a Verification URI (like a Token Endpoint) to retrieve the Access Token.
本机应用程序：在设备上安装并执行代码的公共客户端，该应用程序可能是安全的，也可能不是安全的，但被认为是不安全的。 移动应用程序和本机应用程序均担当此角色，建议再次使用PKCE授权代码授予。 对于无浏览器或输入受限的设备，建议使用“设备代码”流程，该流程在概念上类似于授权代码授予，但要求用户在验证URI(例如令牌端点)上手动输入用户代码(例如客户端密钥)以检索访问权限令牌。
的角色 (Roles)
The spec identifies a few players in the OAuth dance, called “Roles” which are important to keep the flow straight.
该规范确定了OAuth舞蹈中的一些角色，称为“角色”，这些角色对于保持流程顺畅非常重要。
Resource Owner: the user who owns the data being accessed
资源所有者：拥有被访问数据的用户
Resource Server: the api server that provides the user data
资源服务器：提供用户数据的api服务器
Client: the 3rd party app that uses the api to get the user data
客户端：使用api来获取用户数据的第三方应用程序
Authorization Server: the service issuing tokens on behalf of the resource owner (user) to grant access to the data. This may, or may not, co-reside with the Resource Server, it does not really matter.
授权服务器：代表资源所有者(用户)的服务发行令牌，以授予对数据的访问权限。 这可以与资源服务器共存，也可以不共存，这并不重要。
For the purposes of this article I will add one more, the Developer who creates the 3rd party client
为了本文的目的，我将再添加一个创建第三方客户端的开发人员
终点(Endpoints)
There are a few “Endpoints” which need to be established. To you and me these are just URI to get stuff done. The Client needs to know where to ask for authorization, tokens, and refresh tokens. The Authorization Server needs to know where to send info back to the Client.
有一些“端点”需要建立。 对您和我来说，这些只是完成工作的URI。 客户端需要知道在哪里请求授权，令牌和刷新令牌。 授权服务器需要知道将信息发送回客户端的位置。
Authorization Endpoint: A URI on the Authorization Server that provides authorization and the Authorization Code
授权端点：授权服务器上的URI，提供授权和授权代码
Token Endpoint: A URI on the Authorization Server that exchanges the short-lived Authorization Code for a longer lived Access Token, or Refresh Token
令牌端点：授权服务器上的URI，用于将短期授权代码交换为寿命更长的访问令牌或刷新令牌。
Redirection Endpoint: A URI on the client that receives Tokens from the Authorization Server
重定向端点：客户端上的一个URI，用于从授权服务器接收令牌
授权码授予(Authorization Code Grant)
We’ll focus on the Authorization Code Grant in this article. It all comes down to this simplified happy path to unlock our api:
在本文中，我们将重点介绍“授权代码授予”。 一切都归结为解锁我们的api的简化方法：
- Resource Owner (the user) initiates an action on the Client that requests authorization from the Authorization Server 资源所有者(用户)在客户端上发起向授权服务器请求授权的操作
- Authorization Server validates the Resource Owner and Scope of access授权服务器验证资源所有者和访问范围
- Authorization Server sends back a one-time Authorization Code to the Client授权服务器将一次性授权码发送回客户端
- Client exchanges the Authorization Code for a longer-lived Access Token with expiration客户端将授权代码交换为寿命更长的访问令牌，且到期
- Client checks the expiration and if valid uses the Access Token to request User Data via the api, or if expired then the Client requests a Refresh Token or Re-authenticates.客户端检查到期时间，如果有效使用访问令牌通过api请求用户数据，或者如果有效，则客户端请求刷新令牌或重新认证。
In detail, this has the following pattern:
详细地说，它具有以下模式：
开发者(Developer)
As a client developer there are a few things you have to do at the outset:
作为客户开发人员，一开始您需要做一些事情：
- Set up a user and application account on the Authorization Server 在授权服务器上设置用户和应用程序帐户
- Enter the Application Info输入申请信息
- Enter the Redirect URI(s) and/or Callback Domain输入重定向URI和/或回调域
- Get a Client Id获取客户ID
- Get a Client Secret (not needed for PKCE) 获取客户机密(PKCE不需要)
This information establishes the handshake between the Client and Authorization Server.
此信息建立了客户端和授权服务器之间的握手。
例 (Example)
So how does this actually work? Well, let’s suppose that you, the Developer, are building a simple Web Client and you want access to user data through OAuth 2.0. We’ll build the whole flow illustrated above in Go using the Strava OAuth 2.0 service api as an example.
那么，这实际上如何工作？ 好吧，假设您(开发人员)正在构建一个简单的Web客户端，并且您希望通过OAuth 2.0访问用户数据。 我们将以Strava OAuth 2.0服务api为例，构建上面在Go中说明的整个流程。
步骤1：帐户设定 (Step 1: Account Settings)
First we’ll set up for our app. In Strava, this is as easy as:
首先，我们将为我们的应用程序设置。 在Strava中，这很简单：
Go to Strava.com, set up an account if you don’t already have one.
转到Strava.com ，如果您还没有帐户，请设置一个。
- Click on My API Application to set up your Application: 单击我的API应用程序以设置您的应用程序：
Sadly, you will need to upload an icon to edit settings
遗憾的是，您需要上传一个图标来编辑设置
- Enter your Application Name输入您的申请名称
- Choose a Category选择一个类别
- Ignore Club for now现在忽略俱乐部
Enter your Website, for this demo enter https://www.strava.testapp.com
输入您的网站，为此演示输入https://www.strava.testapp.com
Enter your Authorization Callback domain, for this demo enter localhost (localhost is always valid, btw).
输入您的授权回调域，为此演示输入localhost (localhost始终有效，顺便说一句)。
Note the following items, which you will need below (you can come back at any time to view them):
请注意以下您需要的以下项目(您可以随时回来查看它们)：
- Client ID 客户编号
- Client Secret客户机密
The Strava profile also shows an initial Access Token and Refresh Token that you could use right away, but they’re only valid for a few hours (note the expiration), so we’ll get them the right way, with code.
Strava配置文件还显示了您可以立即使用的初始访问令牌和刷新令牌，但是它们仅在几个小时内有效(请注意有效期)，因此我们将通过代码为它们提供正确的方法。
You can extend this example to set up application accounts in LinkedIn, Spotify, and GitHub.
您可以扩展此示例以在LinkedIn ， Spotify和GitHub中设置应用程序帐户。
步骤2：要求授权 (Step 2: Request Authorization)
Now we’ll start writing code. We’ll put together a simple web client to demonstrate a round trip from the Authorization Server, and then extend it. First off we need to bring up the Authorization Page on the Authorization Server. We’ll launch it with a button that does a GET on the Access Endpoint with a query string.
现在，我们将开始编写代码。 我们将组装一个简单的Web客户端，以演示来自Authorization Server的往返行程，然后对其进行扩展。 首先，我们需要在授权服务器上打开“授权页面”。 我们将使用在查询查询字符串在Access Endpoint上执行GET的按钮启动它。
oclient/main.go:
oclient / main.go：
package mainimport (
"fmt"
"html/template"
"log"
"net/http"
"os"
"path"
)func main() {
port := os.Getenv("PORT")
if port
最低0.47元/天 解锁文章
421
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
