This article tags:
http Auth OpenID http validation dafa Session
REST server Become a "certified" old driver
This article is translated from Auth-boss. If there is an inappropriate or incorrect translation of the place, please point out.
Become a certified old driver and understand the different authentication methods on the network.
The purpose of this document is to document and catalog the authentication methods on the Web.
Authentication refers to the process of creating a system through which a user can "log on" to an online service and grant access to a protected resource.
The following references may better summarize what I want to explain:
Client authentication involves proving the identity of a client (or user) to a server on the Web. [1]
W.H.O.
I am a self-taught developer who loves open source technology, learning, coaching and knowledge sharing.
Why
I'm writing this guide because it's hard to find information about verifying this. I decided to put on my "research cap" and do some errands work.
How
My writing style is concise, I will use some technical words.
Disclaimer: This document is not a directory of the network that contains all the authentication methods;
This document is also not intended to provide the "best" authentication method.
No one gave me money to bribe me.
If you want to sponsor me it's better to use some other way, like adopting a puppy or helping people who are working hard.
Citation: These quotations represent the source of my reference.
If you want me to accept the link/better reference my source (not just a link to the original release), I can do so.
If you want me to quote quotations better, of course I would, but please let me know <3 first.
Omission, error:
It's not uncommon to make mistakes, I'm not an expert on security.
If you see something that can be improved, please PR, tell me which lane is wrong, I can improve.
For more information on PR, please see CONTRIBUTIONS.MD.
Hypothetical case
I'll use a common example in this document to illustrate the sign-in process of what happens on the client side (the user is in front of their computer) and on the server (background).
Our example will have an imaginary friend: Beorn.
Beorn likes knitting and often goes to http://knittingworld.com to buy supplies.
Beorn has an account in Knittingworld, we will see an example of his landing.
General Best Practices
Before discussing the techniques for managing authentication, here's what you shouldn't do.
Some of the following items may not be directly related to login/authentication/user registration, but are usually useful.
-
Never store a password as plain text in a database.
-
Don't write your own hashing algorithm (unless you're really smart)
-
Don't write your own authentication technology (again, unless you're really smart).
-
Use HTTPS.
Some advice
We also found that many websites design their own authentication mechanisms to provide a better user experience.
Unfortunately, designers and implementations often do not have a security background and therefore do not have a good understanding of the tools they can use [2]
Terms
There are quite a few terms in the field of web validation development.
Here's a list of terms you'll see below.
HTTP Hypertext Transfer Protocol.
This is a big concept. I can only explain the meaning of it briefly.
The web is built around HTTP -It is the protocol used to communicate between Web servers and users.
Your browser is considered an HTTP client because it sends a request to the HTTP server.
Your customers can make many different types of requests-you may have heard of some of the most popular requests-post post put and delete.
The HTTP server sends a response to your browser-client.
These responses are resources.
Resources can be (but are not limited to): HTML files, images, text, JSON, etc.
You can think of a resource as a "file" returned from the server.
Additional links to this topic:
-
HTTP made really easy
-
RFC2616-This is a document specification for HTTP.
It is listed as expired, but it also lists the documents that supersede it.
HTTPS
HTTPS is a secure HTTP.
It is closely related to SSL/TLS.
The initial payment transactions on the Internet were very popular and recently became more common.
You might think that HTTPS is "green text that appears on the left side of my URL in the browser";
Often accompanied by a lock icon or something like that.
HTTPS is an HTTP encapsulated with TLS (or in the past days, SSL) to protect traffic between the browser and the server.
HTTPS encrypts the information sent with your HTTP request and the response sent back.
This is especially important when we start talking about authentication!
From Wikipedia:
HTTPS creates a secure channel on an unsecured network.
This ensures reasonable protection from eavesdropping and intermediate attacks, as long as sufficient cipher suites are used and server certificates are verified and trusted.
Tls/ssl
TLS and SSL are cryptographic protocols.
TLS and SSL encrypt the data you send over the network-it is designed to prevent people from "eavesdropping" or tampering with the data you are sending.
SSLv2 and V3 are considered unsafe today (see POODLE), so most HTTPS is done using TLS 1.2.
There are some useful videos on YouTube to help explain these complex issues,
This video MIT OpenCourseWare is pretty good!
State
state,stateful,statelessandpiece of state.
These are the terms, they are defined differently.
In this article, "Piece of State" or "stateful" describes a piece of data that is stored in memory.
HTTP requests are typically described as "stateless".
When you visit the website and sign in, you are passing some information along with your HTTP request to identify you.
No matter what authentication method you need to use to identify yourself, you must "attach" to one or another HTTP request, because you cannot simply put that state in the HTTP protocol itself-you have to take another form above the HTTP protocol (as you will see in the remainder of this document). )。
Maybe a little exaggerated ... I think this article from Scotland explains very well the Ins and outs of Token Based authentication.
Since the HTTP protocol is stateless, this means that if we authenticate the user with a username and password, then on the next request, our application will not know who we are.
We must verify again.
Cookies
Cookies are small data stored on the user's browser.
Cookies, in contrast to HTTP, are stateful-which means that although HTTP cannot store user information, cookies can.
Common examples of network cookies:
Beorn visits http://knittingworld.com to buy some nice yarns and materials for his next knitting project.
He logged in and added three items to his shopping cart. Suddenly he heard a bang!
And realized that there was a can of tuna in his microwave. Not good!
Beorn closed the browser and immediately forgot what was in his shopping cart and ran to check the microwave.
Canned tuna sauce has spilled on his home floor, Beorn back to his computer, and re-visited https://knittingworld.com ... Wanted to see if he had been in the shopping cart before.
Cookies.
There are different kinds of cookies.
Some cookies stay in your browser for many days, and other cookies disappear immediately after you close your browser.
Cookies play a big role in the past (still) certification.
Web servers typically use authentication cookies to determine whether a user is logged on and what resources they have access to.
Persistent cookies can sometimes cause problems because they are used by advertisers to record information about the user's web habits.
On the other hand, they are typically used to save users from having to reenter their login credentials each time they visit the site.
You can view the cookies sent with the request by navigating to your (using Chrome) developer tools and opening the Network tab.
The Refresh page displays a list of incoming resources, and you can select one of them.
Scroll through the list to see if the cookie is found!
You can also view information about cookies in the [Application] tab of the developer tools.
Sessions/session Management
I'm not going to try a simple depiction of sessions in the beginning, I'll quote owasp:
A network session is a sequence of network HTTP request and response transactions that are associated with the same user.
Modern and complex web applications need to keep information or state about each user during multiple requests.
Therefore, the session provides the ability to build variables, such as access rights and localization settings, which will apply to each interaction between the user and the WebApp during the session.
You can find an example of session-based authentication in the "Methodologies" section below.
More links to Sessions:
Methodologies
The following is a list of technical solutions for establishing certifications. This is not a complete list!
HTTP Basic Authentication
HTTP Basic authentication (or "Basic Authentication") has existed for a long time. It seems that people tend to use it because of its simplicity, which supports cross-browser. This is a blank page that requires basic validation. Here's how to make sure that WebApp is working properly when Beorn closes the browser again after opening:
-
Beorn went to http://knittingworld.com to buy the yarn.
-
After picking out the yarn, he clicks on the "Buy" button to buy.
-
His browser issues a GET request, and the server response 401 tells him that he needs to be authenticated.
-
Beorn Enter the login form in his username and password.
-
After he clicks on the login, his browser initiates a Get (POST) request and takes authorization in the request. The authorization request header is similar to thisAuthorization:QWxhZGRpbjpvcGVuIHNlc2FtZQ==
-
The server continues to verify the authentication header and determines whether Beorn can submit the purchase operation. The browser remembers authorization, and subsequent requests submitted by each viewer will be added to the requestAuthorization:QWxhZGRpbjpvcGVuIHNlc2FtZQ==header until the viewer is closed.
Some important considerations for HTTP Basic authentication:
-
The above example authorizes the header to look unlike a user name and password, but this is because it is base64 encoded. It is not encrypted.
-
If you use HTTP Basic authentication, use HTTPS. If HTTP is used, the authentication credentials are sent to the server as plaintext. It's not good. The user's username and password are sent through the line only as Base64 encoded text-This is simple for decoding. By using HTTPS/TLS, you ensure that data sent from the client to the server is encrypted.
-
HTTP Basic authentication is implemented by the viewer and is seldom used today.
-
Basic authentication using API?? Basic authentication, when combined with a token, (discussed later) is just an authorization header and is perfectly reasonable. It has the added benefit of not requiring the API client to maintain an additional session cookie, and because most syslog query parameters, rather than headers, will not be logged by default.
-
The combination of Basic authentication and token has many advantages, such as not requiring the client to maintain a single cookie and not being logged by the client.
Link
Session-based authentication
Session certification has been around for some time, and usually used more. The key to session-based authentication is that the user's login is associated with a state of memory on the server or Key-value storage (such as Redis).
Let's take a look at our friend Beorn example using session-based authentication.
-
Beorn to http://knittingworld.com to buy some things.
-
When Beorn logs in, he sends his credentials to the server.
-
When the credentials arrive at the server, the server needs to check whether Beorn is a user in its database in this way or another way. At this point, Beorn is not logged in.
-
Beorn's credentials match successfully, so he can log in.
-
Beorn needs something to identify his future request for the server-especially if he wants to buy something (must log in to buy). This is the idea of the accreditation session.
-
Now that the server knows who Beorn is, and has identified him as a user in the database, the server will send a cookie to him (or "back"), which can list Beorn as a user who has logged in at a later request.
-
Now, Beorn has verified and has a session cookie (one of the cookies) on his browser.
-
When Beorn goes to page http://knittingworld.com/great_deals.html He is making another HTTP request-but this time, his session cookie will be placed in the HTTP request header to the server.
-
The server will authenticate against a cookie that matches the session information in memory (can be saved with a database such as Redis,memcache)
-
When Beorn exits from Http://knittingworld.com, his session instance on the server (or Redis, etc.) will expire and his session cookie will expire.
Token-based authentication
Token-based authentication has become more prevalent recently with the advent of RESTful API applications, single-page applications and microservices.
What is token?
Token is a small piece of data.
The authentication system using token-based authentication means that the user sends tokens to the server to carry out the authentication logic. When an HTTP request is made, token is the credential that verifies that the user is eligible to access the resource.
How is this different from cookie-based authentication?
Token authentication is stateless, and session-based authentication means that a state is stored somewhere in your server (or Redis, etc.) to identify the user.
Auth0 's blog post Cookies vs tokens:the definitive Describe the difference in the authentication process between cookies and tokens:
Session-based authentication process:
1. User enters their login information
2. The server verifies that the information is correct, creates a session, and stores it in the database.
3. The cookie with sessionID will be placed in the user's browser.
4. In subsequent requests, the sessionID is validated against the database, and if valid, the request is accepted
5. Once the user logs out of the application, the session will be destroyed on both the client and server side.
Token-based authentication process:
1. User enters their login information
2. The server verifies that the information is correct and returns the signed token
3. The token is stored on the client, the most common is stored in `local storage`, but can also be stored in the session store or cookie.
4. After the HTTP request, the token is added to the request header.
5. The server decodes the JWT and accepts the request if the token is valid
6. Once the user logs out, the token will be destroyed on the client and there is no need to interact with the server. The key is that the token is stateless. The backend server does not need to save the token or the record of the current session.
Wow, the mark sounds cool. Are they better than session based authentication?
It's the wrong guy, man. I'm just telling you the existence of this verification method. I will not compare meaningless comparisons, I try my best to do this. For more interesting disclaimers, please visit the disclaimer section above. Types of tokens Some common tokens include JWT (discussed below), SWT (Simple network token), and SAML (Security Assertion Markup Language)
Link
-
Token Based authentication-implemenation DEMONSTRATION-W3
-
What is token based authentication-so
-
Token Based authentication Made Easy
-
The Ins and outs of tokens Based authentication
-
Cookies vs Tokens:the Definitive Guide (opinionated)
JWT
The JWT represents "JSON Web Token". JWT is a token-based authentication. JWT is based on web standards. Now more and more JWT is used; JWT is a token-certified one, so JWT is based on token authentication. Thirdly, the different methods of token-based authentication have different advantages and disadvantages. Therefore, much of the information in the token-based authentication section above applies to this.
Summary description from the JWT RFC 7519 normalization: JSON Web Token (JWT) is a compact, URL-safe way to represent a declaration to be transmitted between two parties.
The JSON Web token is a string. It may look like this:
EyJhbGciOIJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab 30rmhrhdcefxjoyzgefonfh7hgq
The above string is what you might see when you use JWT to authenticate, which is the credential that is returned from the server at authentication time. JWT is validated and secure because they use the private key for "digitally signing" and use a key for authentication.
The structure of a JWT?
A JWT is a self-contained block of data. Each JWT consistspayloadof and consists ofsignature. When your server creates tokens, you can also assign unique data to tokens, which you can use on the front-end. This can be used to save the need for additional database calls at a later time. You should still be wary of posting confidential information (such as user passwords, etc.) in tokens sent to customers.
Example functions for creating a JWT token in Python:
def create_token(user):
"""Create a JWT token, set expiry, iat, etc"""
payload = {
‘sub‘: user.id,
‘name‘: user.first_name,
‘role_id‘: user.role_id,
‘iat‘: datetime.utcnow(),
‘exp‘: datetime.utcnow() + timedelta(days=1)
}
token = jwt.encode(payload, MY_SECRET_KEY_SHHH_DONT_TELL_ANYONE, algorithm=‘HS256‘)
return token.decode(‘unicode_escape‘)
The above key SUB,IAT and exp follow the reserved JWT key, but I also added the user's name and role_id. You will need a library to encode/decode the JWT token. Jwt.io lists the libraries for many languages.
Link
Oauth
OAuth is an authentication protocol that allows a user to perform authentication on a server that does not have a password. OAuth exists in many versions-OAuth 1.0,oauth 1.0a and OAuth 2.0.
If you've signed in to a service using a Twitter,google or Facebook account, you've already used OAuth.
、
OAuth providers (Facebook,google, etc.) allow logins by providing a private, unique access token for your service ("OAuth client") authentication method.
If you want to use OAuth to let users sign in to your service, you need to register your server as an OAuth client. This typically sets a client ID and client key. Users who log on to your service will be relocated to the OAuth provider, where they can confirm that they really want to "sign in" (that is, the server that allows them to log on) to access any necessary information for the OAuth provider. In the case of our friend Beorn ...
In the case of our friend Beorn ...
-
Beorn to http://knittingworld.com to buy things.
-
Beorn decided to sign in with his Google account.
-
Prompt Beorn to enter his Google account information (if he is not yet logged in
-
After entering the information, Google (or another OAuth provider) will prompt him if he wants to sign in to http://knittinggworld.com using his Google account.
-
Once accepted, Beorn is redirected to http://knittingworld.com.
-
If Knittingworld needs access to resources about Beorn information, it can request access to the resource server (via the OAuth provider) as long as its token is valid.
owasp says:
It is recommended that you use OAuth 1.0a or OAuth 2.0 because the first version (OAuth1.0) is found to be susceptible to session pinning. OAuth 2.0 relies on HTTPS for security, and currently OAuth APIs, such as Facebook,google,twitter and Microsoft, have been implemented. OAUTH1.0A is difficult to use because it requires the use of an encrypted library for digital signatures. However, because oauth1.0a does not rely on HTTPS for security, it is more suitable for higher-risk transactions.
Link
Openid
OpenID is another authentication protocol (similar to oauth) that does not require a password. The OpenID website has a very concise description, in my opinion:
OpenID allows you to sign in to multiple websites with an existing account without creating a new password. You can choose to associate the information with your OpenID to share it with the websites you visit (such as your name or email address). With OpenID, you can control the amount of information you share with the websites you visit. With OpenID, your password is provided only to your identity provider and the provider confirms the identity of the website you are visiting. In addition to your provider, no website has ever seen your password, so you don't need to worry about an unethical or insecure website that endangers your identity.
Although starting in 2005, recently (2014-H), OpenID released OpenID Connect, a "Interoperable authentication protocol based on the OAuth 2.0 Series Specification" (source)
What is the difference between OpenID and OAuth?
OpenID is similar to OAuth, but there are some differences. Similarly, OpenID relies on an identity provider that interacts with a third party (the site where you are logged on) to provide authentication credentials.
The difference is that you can use OAuth to allow you to log on to a website that has access to data from the provider. This sounds scary and confusing, but here's a simple example:
-
Beorn is registered as Twitter. He wants to sell his knitted hat.
-
Beorn don't know follow who, no one follow him. It's not important to beorn sad feelings.
-
Twitter prompts Beorn to use OAuth to connect to his Google account so that he can import his contacts to Twiiter.
-
Beorn follow a group of people, including old friends from high school he hadn't seen in years.
-
Beorn did so, and now he is tweeting.
Link
-
What is OpenId?
-
OpenId Connect FAQ
-
OpenId Connect Video
-
What ' s the differene between OpenId vs OAuth?
-
What ' s the differene between OpenId vs OAuth? (Different thread)
-
OpenId according to Dave – I like this one, albeit dated
Here is a picture of the login page for stack overflow, which provides a number of different authentication methods:
-
is written at the end: for Freedom look outside the world, and it this line, not to go to Google data, finally, Amway a V--PN agent. a red apricot accelerator , to Google data is the absolute first choice, fast connection, easy to use. I bought 99¥ for a year, through this link (http://my.yizhihongxing.com/aff.php?aff=2509 After registering to pay the coupon code WH80, split down, only 7 yuan per month, special benefits.
This document tags : http Auth OpenID http authentication dafa Session REST server
Turn from SUN's BLOG-focus on Internet knowledge, share the spirit of the Internet!
Original Address: "http validation dafa (Basic auth,session, JWT, Oauth, Openid)"
Related reading : TensorFlow "machine learning": understanding and implementation of fast neural style "quick stylized images"
related reading:" I am a G powder, has been concerned about Google, recently Google has some little gestures, probably a lot of people do not understand "
related reading:" machine learning leads to technological innovation in the field of cognition, so how can the SaaS industry be changed by machine learning?" "
related reading:"VPS Tutorial Series: DNSMASQ + DNSCrypt + SNI Proxy smooth access to Google configuration tutorial "
Related reading: useful for programmers: 2017 latest in Google's Hosts file download and summary of the various hosts encountered the problem of the solution and configuration of the detailed
Related reading: Aaron swartz– The internet genius of the life course: every moment asked himself, now the world what is the most important thing I can participate in doing? "
Related reading: " site environment Apache + PHP + mysql xampp, how to implement a server on the configuration of multiple sites?" "
Related reading: What is the engineer culture? Why are the engineers alive? As an IT or internet company Why should the engineer text
related reading: the Win10 perpetual activation tutorial and how can I see if the Windows system is permanently activated? 》
Related blog:SUN ' S blog -Focus on Internet knowledge and share the spirit of Internet! Go and see:www.whosmall.com
Original address: http://whosmall.com/?post=256
HTTP validation Dafa (Basic auth,session, JWT, Oauth, Openid)