Authentication and authrization (lower)

Note: I would like to write several more articles, but it seems that it is too specific to be put under such a title, so I would like to give a brief introduction here, and then pick up some content based on the situation.

Openid

Openid is an Open Authentication solution, which is related to openid. I have talked about it in my article, but at that time I talked about the earliest version of openid, I don't know which version it is. Now I use openid authentication 2.0 and some of its peripheral extensions. The basic principles of openid auth 2.0 have no essential changes with previous versions, but are enhanced in terms of security and some detailed functions.

The basic login process of openid authentication is as follows:

1. First, the user enters its openid URL on the dependent Party (that is, a third-party website) to log on (you can also directly log on using the provider ID. In this way, no steps 2nd or 3 are involved );
2. (optional) the dependent party performs automatic discovery from the page of the user's openid URL;
3. Obtain the end point URL of the openid provider;
4. (optional) establish an association between the dependent party and the provider;
5. Obtain the associated agreed encryption information;
6. Redirect the user's browser to the provider;
7. the user logs on to the provider and authorizes a third-party authentication request;
8. Return the authentication result (whether the authentication is successful );
9. Redirect the user's browser to the dependent party and submit the authentication result;
10. Rely on the provider to verify the authentication result submitted by the user;
11. Pass user authentication.

After that, the dependent party can save the user submission information in step 1. Each time you need to verify the user identity, repeat steps 9th and 11 to verify the user identity for the provider. Generally, this task is implemented by the session. Because these two steps need to be performed multiple times, and signature verification is required each time for security purposes, we recommend that you use steps 4th and 5 To establish an encryption Association to facilitate subsequent verification operations.

Steps 2nd and 3 in the process are the key to openid distribution, and are also one of the shortcomings (or features) of openid I think in the old article. In this step, users are not limited by specific providers, so that authentication becomes distributed, but the reliability of user authentication is also limited by the website corresponding to this openid URL. Therefore, many openid authentication applications skip this step and use a fixed (or limited number of optional) provider to log on, making Distributed Authentication a third-party centralized authentication. In fact, I personally think this is better. In addition, this can reduce a pair of Network round trips and help improve the logon speed.

There are some additional conventions on this basic authentication. After the basic openid authentication is passed, besides returning the authentication information, the user's profile can also be returned. Of course, the user can choose to verify the returned profile content for the provider. For example, myopenid.com can choose to return a complete profile or a blank profile (but still return the authentication pass message ). A certain protocol is required for a profile.

In openid 2.0, there are two main types: simple registry extension and attribute exchange ).

Simple registration extension defines eight profile fields, which is easier to implement. Property exchange is more powerful. You can specify any number of fields and content fields, which is slightly more complex.

This is also the openid logon method provided by Google to a third party, which adopts the attribute exchange convention.

The property exchange function is to notify the provider of user profile information fields (called attributes) when the dependent party submits a verification request, and then when the user passes the verification, the provider informs the user of the properties requested by the dependent party, and the user determines whether to allow the request (only allow or deny. If the request is rejected, the verification fails and the blank response option is not provided ).

In addition to reading the selected Attribute, attribute exchange can also be used to store the attribute, which must be supported by the provider.

The openid logon process provided by Google to a third party is as follows:

The above is a basic introduction to openid. You can download the source code of various languages on the official website.

Oauth

Oauth is an open authorization solution developed based on openid. Because openid cannot provide the authorization function:

For example, a website a allows users to log on with the openid of the TA, but if a website B needs to use the user data in website, openid cannot be used to securely authorize user data in website a to website B. Although openid information can be provided to website B, log on to website a as a user, but if website B is a malicious website, it can log on to any other website that supports the user to access with the openid as a user, which brings serious security risks.

So people need an open authorization protocol, so oauth was born.

Currently, oauth has two very different versions: oauth 1.0 and oauth 2.0.

Oauth 1.0 is a well-designed Protocol: in addition to the secure authentication process between providers and consumer, it even requires every Data Request (API call) request content must be digitally signed to ensure that nothing is lost.

While oauth 2.0 is equivalent to simplifying oauth 1.0: the provider and consumer simply exchange the key for verification, after that, the consumer can perform data requests (API calls) with only one token obtained after verification, without much signature verification work.

Technically speaking, both versions can implement the authorization function. The difference between the two is that 1.0 is safer, but the cost is greater (the verification process is complicated and the request process is complicated); 2.0 is more convenient, but the security is not as good as 1.0 (for example, the request may be modified during transmission ).

I personally prefer to use the oauth 2.0 + HTTPS solution, which can reduce programming complexity, reduce the probability of errors, and ensure security through HTTPS.

Implementation

For the implementation of the above technologies, please come back later. Temporary plans include: Google openid, Twitter oauth 1.0, Foursquare oauth 2.0