oauth0 oauth2_OAuth的运作方式

oauth0 oauth2

OAuth is one of those technologies that is almost as widely misunderstood as it’s used. In this article, let’s strip away the jargon and really understand how the technology behind OAuth actually works.

OAuth是其中一种几乎被广泛误解的技术。 在本文中，让我们简单地讲一些术语，真正了解OAuth背后的技术是如何工作的。

First of all, as you can guess from the name, OAuth has something to do with Auth. But does auth mean authentication or authorization? Well, the short answer is — OAuth is meant for authorization, not authentication. More importantly, OAuth was originally created not for a service to authorize a person. It was meant for a service to authorize another service. Now why on earth would a service need to be authorized?

首先，您可以从名称中猜出，OAuth与Auth有关。 但是auth是指认证还是授权？ 好吧，简短的答案是— OAuth是用于授权而不是身份验证的。 更重要的是，最初创建OAuth的目的不是为了提供授权人的服务。 这是为了使服务授权另一项服务。 现在为什么需要对服务进行授权？

Did you know: The “Auth” in OAuth is for authorization, not authentication!

您知道吗：OAuth中的“ Auth”用于授权，而非验证！

当两个服务通话时 (When two services talk)

Let’s take a classic example of a photo printing service. You must have seen websites like this. You provide them an image file and you pay them to ship printed photos to your address.

让我们以照片打印服务的经典示例为例。 您一定已经看过这样的网站。 您为他们提供图像文件，并支付他们费用以将打印的照片运送到您的地址。

Imagine you are starting a new photo printing business. You build a website that lets people upload photos and order prints online. Now, here’s the thing. Nobody keeps photos on their machines anymore. They use the cloud! And so you keep getting feature requests to provide users the ability to import their photos from somewhere like Google Drive and then print it directly from there, without the users having to download them and upload again.

想象您正在开始新的照片打印业务。 您建立了一个网站，人们可以在线上传照片和订购照片。 现在，这是事情。 没有人将照片保存在他们的机器上了。 他们使用云！ 因此，您会不断收到功能请求，以使用户能够从Google云端硬盘之类的位置导入他们的照片，然后直接从那里打印，而无需用户下载并重新上传。

Okay, that’s a fair ask. Now what do you have to do to implement an Import from Google Drive feature for your application? You need to connect to the user’s Google Drive account and access their files. But wait! How can your application do that? The user’s files on Google Drive needs the user’s Google authentication. How can you write code for your website that can authenticate with Google on behalf of your users?

好的，这是一个公平的要求。 现在，要为您的应用程序实现从Google云端硬盘导入功能，您需要做什么？ 您需要连接到用户的Google云端硬盘帐户并访问其文件。 可是等等！ 您的应用程序如何做到这一点？ 用户在Google云端硬盘上的文件需要用户的Google身份验证 。 您如何为您的网站编写可以代表您的用户通过Google身份验证的代码？

Well, here’s something you can do. You can ask the user for their Google ID and password. Your app could say:

好吧，这是您可以做的。 您可以要求用户提供其Google ID和密码。 您的应用可能会说：

“Hey user, do you want me to print your photos on Google? Well, Google doesn’t give me access. So, here’s this screen where you enter your Google ID and password. Give them to me, and I’ll login to your Google account and access your photos and print them”.

“嘿，用户，您要我在Google上打印照片吗？ 好的，Google不允许我访问。 因此，在此屏幕上，您可以输入Google ID和密码。 把它们给我，我将登录到您的Google帐户并访问您的照片并进行打印”。

Do you think users will hand your photo printing service their Google ID and password? They don’t trust you! What they want to give you is access to just certain photos. They don’t want to give you access to their whole Google drive and email and everything else. Your service might pinky-promise that it’ll access just their photos, but there is no guarantee! So, while this works in theory, this is not practical.

您认为用户会将您的照片打印服务的Google ID和密码交给您吗？ 他们不相信你！ 他们想给您的只是访问某些照片 。 他们不想让您访问整个Google驱动器，电子邮件以及其他所有内容 。 您的服务可能会承诺会仅访问他们的照片，但不能保证！ 因此，尽管这在理论上可行，但这是不实际的。

Now you might say — Google Drive has a share feature! You can ask the user to share the files out and then provide the shared link to your service. But there are problems there too. What if the users don’t want to share files out to anyone. Also, what if it’s a different scenario where sharing isn’t an option? For example, think of a scenario where your service wants to access the user’s contacts to send app invites? There’s no way you can ask the user to share their address book. Such a feature doesn’t even exist! So, how do you have a third party service authorize with a service like Google without your user providing it their credentials?

现在您可能会说-Google云端硬盘具有共享功能！ 您可以要求用户共享文件，然后提供指向您服务的共享链接。 但是那里也有问题。 如果用户不想与任何人共享文件怎么办。 另外，如果在不同的情况下无法共享该怎么办？ 例如，考虑您的服务要访问用户的联系人以发送应用邀请的情况？ 您无法要求用户共享其地址簿。 这样的功能甚至不存在！ 那么，您如何在没有用户提供其凭据的情况下让第三方服务获得Google之类的服务的授权？

输入OAuth (Enter OAuth)

To solve this problem of services trying to access each other on behalf of the user, there was a standard protocol created called OAuth. The first version of the standard, now called OAuth 1, wasn’t that popular. But the current version, OAuth 2, is very widely used and adopted. When anyone mentions OAuth these days, they are almost always referring to OAuth 2.

为了解决服务试图代表用户彼此访问的服务的问题，创建了一个称为OAuth的标准协议。 该标准的第一个版本(现称为OAuth 1)并不流行。 但是当前的OAuth 2版本已被广泛使用和采用。 如今，当有人提到OAuth时，他们几乎总是在指OAuth 2。

Okay, so how does OAuth work? A very commonly used analogy that’s used to help people understand OAuth is the valet key model for cars. Let me explain.

好的，OAuth如何运作？ 一个用来帮助人们理解OAuth的非常常用的类比是汽车的代客密钥模型。 让我解释。

代客问题 (The valet problem)

Think of how parking attendants or valets work. The idea is that a car owner drives up to a parking garage, and instead of fighting for a parking spot. themselves, they just get down, hand their key to the valet and say, “Hey Mr Valet guy, park my car for me”. The valet takes the key, drives the car, finds a spot and parks the car.

想想停车服务员或代客的工作方式。 这个想法是，车主开车到停车场，而不是争夺停车位。 他们自己下来就把钥匙交给代客，说：“嘿代客先生，为我停好车。” 代客拿钥匙，开汽车，找到地点停车。

Now I wouldn’t have a problem handing my beat-up old car to any valet. But imagine if a rich guy pulling in with a million dollar sports car. They would be justified in being a little hesitant to hand over the keys. What if a malicious valet picks up the keys and takes the car for a long drive or opens the trunk or glove compartment?

现在，将老旧的汽车交给任何代客服务都没有问题。 但是想像一下，如果有钱人带上一百万美元的跑车。 他们会有些犹豫地交出钥匙，这是有道理的。 如果恶意代客拿起钥匙并开车开车或打开行李箱或杂物箱怎么办？

This is why some cars come with an additional key called the valet key. This key is just like the main car key but with reduced access. It can start and stop the car. But it cannot open the trunk or the glove compartment. It cannot open the fuel tank. Stuff like that. If the sports car owner has such a key, they would be more comfortable handing this key to the valet.They know the valet cannot do a whole lot with that key apart from their intended purpose.

这就是为什么有些汽车带有一个称为代客钥匙的附加钥匙的原因。 该钥匙就像汽车的主钥匙一样，但是访问较少。 它可以启动和停止汽车。 但是它无法打开行李箱或手套箱。 它无法打开油箱。 类似的东西。 如果跑车拥有者拥有这样的钥匙，他们将把钥匙交给代客会更自在，他们知道代客除了要达到预定的目的外不能用钥匙做很多事情。

So, here the car owner is using two “services”. The car service and the valet service. The valet service needs to access the car service directly to do the job. So, rather than give the complete “credentials” of the car service to the valet service, the car owner gives reduced or limited access to the car service.

因此，这里的车主正在使用两项“服务”。 汽车服务和代客泊车服务。 代客服务需要直接访问汽车服务才能完成工作。 因此，车主没有将汽车服务的完整“凭证”交给代客服务，而是减少了或限制了对汽车服务的访问。

OAuth流程 (The OAuth flow)

OAuth is an authorization mechanism where services can authorize against each other on your behalf once you’ve given them permission. It is often referred to as delegated access for this reason. It is also an open standard — as it obviously needs to be — because multiple services over the internet need to talk to each other. So there is a specification that all these services need to follow so that they understand each other. There is a certain flow that needs to happen for this whole process to work — the OAuth flow.

OAuth是一种授权机制， 一旦获得许可 ，服务就可以代表您相互授权。 因此，通常将其称为委托访问 。 它显然也是必需的，也是一种开放标准，因为Internet上的多种服务需要相互通信。 因此有一个规范，所有这些服务都需要遵循，以便彼此理解。 为了使整个流程正常工作，需要执行某些流程-OAuth流程 。

OAuth is an authorization mechanism where services can authorize against each other on your behalf once you’ve given them permission. It is often referred to as delegated access for this reason.

OAuth是一种授权机制，在您授予服务权限后，服务可以代表您彼此进行授权。 因此，通常将其称为委托访问 。

Back to our photo printing example. Here’s the situation:

回到我们的照片打印示例。 情况如下：

1. You have a service that needs to access the user’s Google Drive files
   您拥有一项需要访问用户的Google云端硬盘文件的服务
2. We have a user who is logged into both this service and to Google. Both services trust the user. They just don’t trust each other.
   我们有一个同时登录此服务和Google的用户。 两种服务都信任用户。 他们只是彼此不信任。
3. The problem we want to solve is to have these two services work with each other.
   我们要解决的问题是使这两个服务相互配合。

If both these services have OAuth implemented, here’s how the interaction works

如果这两个服务都实现了OAuth，则以下是交互的工作方式

1. The photo print service goes to Google and says, “Hey, I need this user’s files”.
   照片打印服务转到Google，并说：“嘿，我需要该用户的文件”。
2. With OAuth implemented, Google does something interesting. It goes to the user and says “Look here, user. There’s this service here that wants to access some of your files. Is this legit? Here’s the list of things this service wants to do. Shall I go ahead and allow it?”
   实施OAuth后，Google会做一些有趣的事情。 它会向用户说：“用户，请看这里。 这里有此服务想要访问您的某些文件。 这是合法的吗？ 这是此服务要执行的操作的列表。 我可以继续接受吗？”

3. Now the user sees a screen that clearly specifies A) Who is asking for access to the user’s Google account and B) What’s the list of permissions that the service wants.

   现在，用户将看到一个屏幕，其中清楚地指定了A) 谁正在请求访问用户的Google帐户，以及B)服务需要的权限列表是什么。

4. Now if the user is the person who is trying to print the photo, they’ll look at that and say “Okay, this is all correct. Please allow access”.
   现在，如果用户是尝试打印照片的人，他们将看一眼并说“好吧，这都是正确的。 请允许访问”。
5. Now Google has reason to trust the service, so it gives the service a key token (called the authorization token) that contains all the allowed permissions. It’s a limited access token. A “valet key token”, if you will!
   现在Google有理由信任该服务，因此它为该服务提供了一个包含所有允许的权限的密钥令牌(称为授权令牌)。 这是一个受限的访问令牌。 如果您愿意，可以使用“代客钥匙令牌”！
6. And now every time the photo printing service needs to access the Google Drive, it just hands this token with the request and says “Hey Google, I need access to that file. Here’s the token that you gave me which has user verified access to these permissions. Let me in!”
   现在，每次照片打印服务需要访问Google云端硬盘时，它都会将令牌与请求一起交给您，并说：“嘿，Google，我需要访问该文件。 这是您给我的令牌，该令牌具有用户验证的对这些权限的访问权限。 让我进去！”

7. And each time this happens, Google looks at the token and says “Hmm, okay, that’s legit. You can access this”. With the token, the photo service has limited access to only the permissions the user has previously approved

   每次发生这种情况时，Google都会查看令牌，并说：“嗯，那是合法的。 您可以访问此”。 使用令牌，照片服务只能访问用户先前批准的权限

You might have seen these screens from Facebook or Google asking for permissions.

您可能已经从Facebook或Google看到了这些屏幕，要求获得许可。

The screen informs you which service is trying to access what permissions on your behalf. If you accept, an access token is handed to the service which allows future access so that you don’t have to click allow every time.

屏幕将通知您哪个服务正在尝试代表您访问哪些权限。 如果您接受，则将访问令牌传递给该服务，该令牌允许将来进行访问，因此您不必每次都单击允许。

访问令牌 (Access token)

What does this access token look like? It has to be a token that contains information about all the allowed permissions and also needs to be tamper-proof — something that the service can verify. How do you create a token that can contain data within it but is also secure so that it cannot be modified? There is a specific token format called JWT that works perfectly. Check out this article to learn how JWT works!

此访问令牌是什么样的？ 它必须是一个令牌，其中包含有关所有允许的权限的信息，并且还需要防篡改(服务可以验证的东西)。 如何创建一个可以在其中包含数据但又很安全以使其无法修改的令牌？ 有一种称为JWT的特定令牌格式可以很好地工作。 查看本文 ，了解JWT的工作原理！

Now that you know how this flow works, it is also obvious to see why OAuth is used for authorization, not authentication. In this case, the user is actually authenticated to both the services already. The problem being solved here is how to authorize one service with another.

既然您知道了该流程的工作原理，那么很明显就能知道为什么将OAuth用于授权而不是身份验证。 在这种情况下，实际上已经向用户验证了两个服务。 此处要解决的问题是如何授权一项服务与另一项服务。

Now that you know the OAuth flow, the next time you see these OAuth access consent screens, you’ll know what’s happening and why!

现在，您已经知道了OAuth流程，下一次看到这些OAuth访问同意屏幕时，您将知道发生了什么以及为什么！

翻译自: https://medium.com/weekly-webtips/how-oauth-works-87fb582c6a6b

oauth0 oauth2