Within the most current concepts for secure development, dealing with the authentication aspect is one of the most important of them. Today we are going to address two models: SAML and OAuth.
You can also listen to this article:
I believe that a first step is to talk a little about what Federated Identity is, as this will be important to understand why these two concepts are so used when working with secure development.
First let’s get to a disclaimer, knowing that SAML is an authentication standard while OAuth is an authorization standard, we will try to explain here the use of these two standards.
What is Federated Identity?
If I need to explain what Federation Identity is in a nutshell, I would say that it is the possibility for a user to be authenticated in multiple systems, after being validated by a central authentication mechanism. This process is related to SSO or single sign-on, which is a subset of Federated Identity Management.
But, hey, attention: so far we are only talking about authentication!
Even though this concept has brought the possibility of authenticating users within the same domain, or network, today we have the possibility of also using the same concept to validate users’ cross-domains, that is, the possibility of using an authenticated user in a domain in another domain.
I don’t want to go into too much detail here, but understand: there’s a lot more to be studied when dealing with the concept of Federated Identity, and I suggest you look for more information and two good documents that can help with this are NIST 800-63C and NISTIR 8149.
Let’s go ahead and talk a little more about the topic of the article.
What is SAML – Security Assertion Markup Language
Basically, we can explain SAML or Security Assertion Markup Language as a standard that was created with a very clear purpose to meet the need to allow cross-domain single sign-on (SSO). This allows a user already authenticated on one system to be authenticated on another system, proving that they are already authenticated on another system, and the system that wants to authenticate the user to trust the system that authenticated them previously.
The concept and use of SAML is not new, it has been among developers and systems since 2005, therefore a mature and tested standard.
Currently in its version 2 (SAMLv2), it is widely used and has an even more evident use when dealing with corporate and government systems. In a very basic way, what we have is XML to represent the user’s digital identity and the HTTP protocol as a transport mechanism for this information.
How SAML works
As we mentioned above, SAML is an XML-based authentication protocol, where an identity provider stores and validates a user’s credentials. This validated digital identity is then used to authenticate the user to other systems.
In this structure, we have some “characters” such as the SP or Service Provider that is the provider of the service that the user is trying to access. In addition to it, we have the RP or Relying Party, which is the service within the SP that is requesting and receiving data from the IdP (Identity Provider).
If the example was a little complicated, imagine that you are traveling internationally and when you arrive in the destination country, you need to present your passport, which will be validated to allow your access. I think that makes it easier, don’t you?
What are the benefits of SAML?
Well, for sure I’ll miss some, but let’s go to the ones I can think of right now.
I believe that the first is the convenience for the user, as it allows him to perform only one authentication process and can use other systems. With that, the second benefit immediately comes to my mind, which is clearly an increase in the security of the authentication process, as it prevents the user’s credential from being taken to many points.
Another benefit is that, being a standard, it facilitates the action of developers who can now understand only a single authentication concept, and in addition to achieving one more benefit, the possibility of compliance with required standards.
I’m sure I forgot some benefit, and it would be really cool if you could put it in the comments.
Well, I believe we can now move on to the second theme, OAuth.
OAuth2
In 2012 the OAuth2.0 model became a de facto industry standard, and like the previous ones, the OAuth standard is used when a user or even a system needs access to some resource. So in this way OAuth2.0 is a standard that allows a user or system to gain permission to perform activities on another system.
As we have already stated above, OAuth is an authorization pattern and not an authentication pattern.
OAuth2 uses Access Tokens, which are data representing authorization information to access the resource. In the OAuth2 documentation there is no definition of a specific standard for an Access Token format, however it is not uncommon to see the JSON Web Token (JWT) being used.
It is important that we know some (or perhaps all) of the functions present in OAuth2, so I decided to put some here.
The Resource Owner may or may not give permission to use the resource to which access is desired. When you want to use a resource, it is in this function that whoever requests this authorization will be indicated. Consequently, it is normal for the name of the function that requests access, that requests authorization, to be Client.
The Authorization Server receives a request from the Client and issues the Access Token to the same Client, provided that it is duly authenticated by the Rource Owner. Finally, we will talk about the Resource Server, which is basically responsible for protecting the user’s resources and is the one that receives requests and validates a token from the Clients, and if everything is correct, it returns the appropriate resources to the Client.
If it got complicated, there’s an image below to help
I believe it is now much easier to understand, right?
Cool, but there’s a point that is very important and we haven’t talked about it yet, the OAuth2.0 Scope. It is responsible for providing the Authorization Server with the reasons that should lead to authorization or granting access permission. Okay, I understand, but what is the Scope?
Well, the Scope is the identification of which resources the Client is trying to access, it’s just the way we have to identify what we have to grant permission to, and that depends a lot on the Resource Server.
Well, I think we managed to deliver the basics in this article, but there is still much more than that, what we talk about here is just very superficial content, there are many important and interesting documents to study, and in them the content is much more detailed, just look for it .
As always, anything you want to share or ask, leave it in the comments. If I know the answer, I’ll answer, if I don’t , I’ll look it up and share it with you.
See you next time!
