OpenID Connect 1.0 On Fingers
At OpenID Connect there is a specification , there are tutorials, articles on habr and not on habr. It is rather senseless to sculpt another step-by-step instruction, leading from deep bewilderment to working pass-through authorization and authentication. The task of the text below is different, to describe the ideas underlying the specifications (there are more than one).
I will not bounce on the topic of the article right away, but I will start with simple things and many obvious ones. I will continue with how they developed and what drew on them according to the requirements of the customers. I approach him historically, that is, the very way he came into being.
The task at least - just do not let anyone get to some of its resources. We close it with a username / password, who knows the appropriate pair from the login and password will get to the resource, who does not - no. This thing is called authentication , for it you can use not only logins with passwords (code from SMS, for example, or a hardware USB key), but these details are not essential for our topic. I will also omit the obligatory paragraph about the danger of transmitting passwords over the Internet in open form, for which we all do not like Basic access authentication .
I'd rather note this: none of the users like to enter logins with passwords. SMS codes are no better, and USB keys just hate it at all. In order not to force the user to enter a login with a password for each request, the server in response to them sends a line of abracadabra, called a session key . And then this key clings the client to each request to the server (usually an HTTP header, but this is not essential), and the server checks if it has such a session.
Session with the key - phenomena, by definition, temporary, the golden ratio for the session lifetime is approximately “while the browser tab is open, but not longer than a day”
Let someone go - it's good. Now you need to understand who we let. And not only to bring out what he entered as a name in the upper right corner, but also to decide what to allow him and what not.
And all this is called - authorization . And I'm not sure about you, but I confuse it with authentication all the time. In order not to be confused - with regard to the mnemonic rule, “authorization” - from the word “author”, “author” they write on the covers of books, and there they never write “a validated member of the Writers' Union”. The author is always a very specific person. So, authorization is a process when we understand whom we specifically run by login and password.
OK. We have a website, there is something secret on the website, at the entrance to the secret part we require a password, each of them only shows its secrets, and does not show others. Life does not stand still, and we have another site. And here we again meet the problem from point 1, no one likes to enter logins and passwords! You can combine the user base and it will save them from having to register twice, but how to save them from re-entering their login and password at the entrance? Given the existence of such a thing as the Same Origin Policy (and our sites are, of course, on different domains, it means that cookies with the session key are not visible to another)? Here, to give importance to the moment, I will start a new item.
SSO , Single Sign On - whatever the implementation, Microsoft's Kerberos, SAML or something OAuth 2.0 , on top of which OpenID Connect is built , about which I am writing to you here, is actually the same thing under the hood: there is a separate server authorization , and anyone who wants to authorize the user redirects the user to him. If the user is already authorized, the session is picked up, and he immediately flies away from the authorization server back and hits where he wanted. If not authorized, the authorization server solves this problem as best it can, asking for a login with a password, as a rule, and, if successfully resolved, sends the user back.
At the same time, SAML is currently an outdated solution. And Kerberos is a completely separate, closed Maycrosoft magic that goes far beyond the HTTP protocol. Well, we focus on it. And then we come to the next problem.
There is already a clear scenario of work - in any incomprehensible situation, send the user to the authorization server, let him decide what to do with it and return the finished answer. But how exactly will the authorization server tell the other server that the user is authorized? Here we return again to the ideas of the first point, namely, to the session key. Let's return to the sources: the presence of the session key is a sign of authorization, the session key itself unlocks the door to the user information, and, you won’t believe, the information about the session. This means that the authorization server authorizes and gives the session key to another server.
Now, however, it is no longer called a session key, but a token .
Or rather, (according to the OAuth 2.0 protocol , on top of which OpenID Connect is written), there are two tokens at once - Access Token , to cling it to all requests like grandfathers hooked session keys, and Refresh Token , to update Access Token when it goes dead.
Let's sum up the intermediate result. Instead of asking the user for a username and password, the server sends it to another server, a separate authorization server. He does all the work, and then gives the first tokens. Exactly according to this scenario, applications, mobile and sometimes desktop, are authorized. They do not make any redirects, they simply send JSON with login and password to the authorization server, and the latter sends them tokens in response.
Mobile and desktop applications as you can. Somehow they are considered safer than the web, but life on the web is more complicated.
On the one hand, it is not more complicated, but vice versa is simpler. You can make a redirect and not bother yourself with drawing a login and password form. On the other hand, I really, really don't want to drag the tokens through the browser in the open form. It is almost as disgustingly insecure as an unencrypted password in Basic access authentication . But no one wants to repeat that old terrible mistake.
The solution to the problem was found not to say that it is very elegant, but working. At first, everything goes as usual, the transition to authorization, the actual authorization. Then, when it comes time to go back with tokens, a reverse redirect occurs. But instead of tokens, a one-time code is attached to the return address. The one-time code is just generated by the authorization server only for that particular moment. He has a very short lifetime. As soon as a one-time code was received, another server had to tuck the skirts, eyes bulging and rush to the authorization server again urgently - in order to receive the desired tokens using the one-time code.
For a hike with the code for the tokens on the authorization server there is a special resource. It accepts, according to the specification, not GET, but POST. What as it hints to us that this request should be done not from the browser, but from server to server.
For the same reason, on any self-respecting authorization CORS server for POST requests is prohibited.
By the way, do you still remember about authentication and authorization? Authentication is when someone is simply allowed to login and password, or not allowed. And authorization is when already started up, they begin to figure out who exactly was allowed.
Do you remember about OAuth 2.0 ? I mentioned it a couple of times above, as some kind of foundation for OpenID Connect.
And remember about OpenID Connect ? This article is just him mute.
So, OAuth 2.0 is authentication. All the previously described slightly complicated procedure with three participants, a password, a code and a token is all about authentication, just about launching someone somewhere. OAuth 2.0 protocol.
OpenID Connect is authorization. That is, it adds to OAuth those parts where it turns out who was allowed.
To do this, another one is added to the list of tokens, it is called ID Token . Those who followed the link are probably surprised without meeting anything about any ID Token. Let surprise not turn into fright, ID Token is JWT , returned as a base64-encoded matryoshka in the same JSON as Access Token and Refresh Token. In any case, everything you wanted to know about the user is in it.
And there is also a special resource on the authorization server called userinfo, where you can knock on Access Token, and get back the same JSON as in ID Token. But why is it needed if the ID Token is already there? Question to the authors of the specs.
OpenID Connect also contains descriptions of various user information fields. How can this information be obtained, directly during authorization or at any time after. And a description of how and when the user will allow you to use this information.
Or not allowed. So, in short, and OpenID Connect 1.0 is arranged.
A little tinsel in the protocol. I hope that you are tired enough of reading the article at the moment, so as not to give this item a lot of attention, just running through his eyes. Here I will mention the parameters that are in the specification, and they carry some semantic load, but the implementation of the idea itself is not directly related. Basically, they add security, well, or just let you pass some information from one of the participants to the other, if necessary.
Client ID and Client Secret . Client in the language of the OpenID Connect protocol is not a browser at all, but the very other server that needs to be authorized by the user. Suppose you have a website, and you want to fasten to it a trendy authorization through Facebook. And through googol. And not so fashionable through Twitter. Implementing a protocol in code is not enough. You will also need to register with Facebook, Google, and Twitter, but not as a user, but as the same client who, as a server, can use their authorization. When registering, you will receive from the conditional Facebook Client ID and Client Secret. And when requesting authorization, among other things, send the Client ID. And when you go with a one-time code for a token, Client Secret will also be required from you.
Redirect URI . It's simple. When sending a user to a conditional Facebook login, you need to tell Facebook where to return the codes and tokens after authorization. Of course, you still give him your Client ID. But a separate Redirect URI allows you to transfer after authorization different users to different pages, for example admins on the admin area, and ordinary users to their personal pages. Practical In addition, the permitted list of possible Redirect URIs specified in the client settings on the conditional Facebook is an additional security.
Scope . This is a list of what the server wants to know about the user from the authorization server. The values in the list are separated by spaces, openid among them must be, and then read the specification.
State . Remember about the one-time code for which tokens are issued, like a coupon in an electronic queue? So, a state is a code on the contrary, if the authorization server issues a code to another server so that it will soon return it, that state another server issues to the authorization server so that it returns it during a redirect. I need it, as far as I understand, in case the other server has already managed to create its own session so that it is not lost in all these redirects.
There are other parameters, such as the type of request for authorization and the lifetime of tokens, but to understand why you don’t need them.
In conclusion. I really hope that not too thoughtful and focused reading of the text above somewhere helped you to grasp the ideas underlying some modern access control protocols. But starting the implementation, or simply setting up any of them, open the spec, find a good tutorial, and carefully follow each word and each letter. And let the understanding of ideas wake up in you and intuition. But let your intuition bite you in the crown every time you miss some insignificant, at first glance, parameter or setting, and leave it a hole for the sweaty naughty little hands.
Remember that this is still security, and its rules, no matter how silly and meaningless they seem, are written in blood. Well, maybe not entirely in blood, this is not a safety technique in the foundry, in the end, but money and reputation for sure, and money and reputation are also not the kind of things that should be scattered like that.
Thank you JM for the fact that the text you read was much better than the one I wrote.
Good luck to you, and do not forget to renew certificates in time.