Nowadays security has become more important than ever. Implementing the right standards is required for applications to grant access to resources in an expected way. Oftentimes instead of implementing your own solutions, it is possible to apply proven standards that the industry has been using for years.  This approach might yield numerous benefits, such as:

  • the economy of time;
  • hassle-free implementation due to broadly available documentation;
  • much easier solving of problems as communities using the same solutions are keen on sharing their knowledge,
  • in most cases continuous support and adaptation to changing standards;
  • and above all, the safety of using a proven, tested solution.

Therefore, should you be interested in ready-made standards and management of authorisation for many platforms, it is worth considering OAuth and SAML. Before we discuss them in detail, it is important that we differentiate between authentication and authorisation.

What is the Difference between Authorisation and Authentication?

Authorisation is a process that aims to control access of an user who wants to use some service.

The purpose of authentication is to verify the identity of an entity, i.e. to confirm that they really are who they claim to be.

Authorisation is usually preceded by authentication. To illustrate this, imagine a John Smith who is the only person who can enter a secret office in a building using his mobile app. First, he would need to log in using his login an password in the application – this is authentication. Subsequently, as he would proceed to enter, his access would be verified in a process called authorisation.

OAuth Protocol

This article will predominantly concern OAuth 2.0, an open protocol allowing to build safe authorisation mechanisms for various platforms, e.g. Internet applications, mobile apps, etc. One particularly interesting fact is that this protocol requires neither passwords nor authorisation tokens.  An authorisation token is a string of characters defining the scope of access granted for a specific period of time. This standard is used, among others, by Google, Microsoft and Facebook.

Importantly, OAuth 2.0 is used to delegate authorisation to resources. In other words, the owner of the resource that we want to access can grant us access to this resource for a given amount of time and on defined conditions.

What Is the Process Like? – the Autorization Code Flow Method of the OAuth Standard

Authorization Code Flow is the best known method of authorization for the discussed standard. It allows to perform actions on behalf of the user.

Look at the picture no. 1

  • Imagine a user who wants to access data from the Resource Server.
  • The client redirects the user to the authorisation server that issues validation on behalf of the owner of the resource. With proper validation, the client gains access to protected data stored on the resource server.
  • The authorisation server sends a log-in form and/or a so-called consent screen (optionally, if there is no session). The consent screen form informs the owner of the protected resource what information and permissions are requested by the client.
  • The user proceeds with authentication and confirms delegating the permissions (optionally, if there is no session).
  • The authorisation server verifies the user and redirects them to the client together with an authorisation code.
  • The client presents the obtained authorisation code.
  • The authorisation server returns an access token to the client.
  • A notification on access to the data with the access token is sent.
  • The client is granted access to the secured resource. The user is granted access to the secure data.

OAuth2 in Android

val uri = Uri.parse(authorizationUrl)
.buildUpon()
.appendQueryParameter("client_id", clientID)
.appendQueryParameter("redirect_uri", redirectUri)
.appendQueryParameter("response_type", "code")
.appendQueryParameter("scope", „phone_number”)
.build(

We build a URL in order to obtain authorization_code.

Here we intercept the redirect, obtain the authorization code and request the token.

val response = createNetworkClient().post(authorizationtokenUrl) {
parameter("client_id", clientID)
parameter("client_secret", clientSecret)
parameter("code", authorizationCode)
parameter("grant_type", "authorization_code")
parameter("redirect_uri", redirectUri)
}

We send a POST request in order to obtain the token.

A correct structure should look as follows:

@Serializable
data class OAuthAccessTokenResponse(
@SerialName("access_token") val accessToken: String,
@SerialName("refresh_token") val refreshToken: String? = null,
@SerialName("expires_in") val expiresInSeconds: Int? = null,
@SerialName("token_type") val tokenType: String? = null,
@SerialName("scope") val scopes: List? = null,
)

Implementation on the Example of Angular

Auth0 Angular SDK provides methods of initiating authorisation events in Angular components: logging in, logging out and registration.

Installing OAuth package:

ng add @auth0/auth0-angular@1.11.1

Initiating the process of logging in:

export class LoginButtonComponent implements OnInit {
constructor(public auth: AuthService) {}
ngOnInit(): void {}
loginWithRedirect(): void {
this.auth.loginWithRedirect();
  }
}

Within the LoginButtonComponent definition, auth.loginWithRedirect() is a method provided by AuthService. This method asks users to authorise and confirm the request, in effect authorising, on behalf of the user, an Angular application to access specific data.  In the present context it means that your Angular application redirects the user to an Auth0 Universal Login website in order to process authentication.

Taking a Closer Look at the SAML Protocol

A well-known Internet protocol, the SAML (Security Assertion Markup Language) enables logging in with the use of one set of certificates and obtaining access to many applications.    It was developed by the Security Services Technical Committee of OASIS to implement authentication and transfer identities along with their attributes between computer systems.

Based on XML, the standard enables flexible sharing of data required for authentication and authorisation, applying standard web methods (e.g. GET, POST). Thanks to this, the standard is free from the limitations typical of architecture or solutions of providers.

The Functioning of SAML

Look at the picture no. 2

  • The User wants to access the service.
  • The Service Provider verifies whether the User has a SAML token.
  • The Service redirects the User to the Identity Provider.
  • The Identity Provider outputs a login form (optionally, if there is no session).
  • The User confirms their identity by means of authentication (optionally, if there is no session).
  • The Identity Provider authenticates the User and creates an SAML token.
  • The Identity Provider outputs the SAML token and the User is redirected to the Service Provider.
  • The Service Provider verifies the SAML token. The User is granted access to the service.

SAML on the Example of Authentication

In order to authenticate the user, services in the Cloud send AuthnRequest elements to Azure AD. An SAML 2.0 AuthnRequest code might be similar to the following example:

<samlp:AuthnRequest
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
ID="id6c1c178c166d486687be4aaf5e482730"
Version="2.0" IssueInstant="2013-03-18T03:28:54.1839884Z"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://www.app
</Issuer>
</samlp:AuthnRequest>

To better demonstrate this, let us use an example of a LightSaml library:

$authnRequest = new LightSamlModelProtocolAuthnRequest();
$authnRequest
->setProtocolBinding(LightSamlSamlConstants::BINDING_SAML2_HTTP_POST)
->setID(LightSamlHelper::generateID())    
->setIssueInstant(new DateTime())
->setIssuer(new LightSamlModelAssertionIssuer(‚https://www.app/‚))

required parameters:

  • ID – an identifier
  • Version – the value should be set to 2.0
  • IssueInstant – a DateTime string with a UTC value
  • Issuer – the URI of the identifier of the application defined during the registration of the application.

After logging-in successfully, Azure AD will output a response to the service in the Cloud. 

<samlp:Response ID="_a4958bfd-e107-4e67-b06d-0d85ade2e76a" Version="2.0" IssueInstant="2013-03-18T07:38:15.144Z" Destination="https://contoso.com/… InResponseTo="id758d0ef385634593a77bdf7e632984b6" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> https://login.microsoftonline.com/…>
<ds:Signature xmlns:ds="https://www.w3.org/…>

</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_bf9c623d-cc20-407a-9a59-c2d0aee84d12" IssueInstant="2013-03-18T07:38:15.144Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>https://login.microsoftonline.com/…>
<ds:Signature xmlns:ds="https://www.w3.org/…>

</ds:Signature>
<Subject>
<NameID>Uz2Pqz1X7pxe4XLWxV9KJQ+n59d573SepSAkuYKSde8=</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="id758d0ef385634593a77bdf7e632984b6" NotOnOrAfter="2013-03-18T07:43:15.144Z" Recipient="https://contoso.com/… />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2013-03-18T07:38:15.128Z" NotOnOrAfter="2013-03-18T08:48:15.128Z">
<AudienceRestriction>
<Audience>https://www.app</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/…>
<AttributeValue>testuser@contoso.com</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/…>
<AttributeValue>3F2504E0-4F89-11D3-9A0C-0305E82C3301</AttributeValue>
</Attribute>

</AttributeStatement>
<AuthnStatement AuthnInstant="2013-03-18T07:33:56.000Z" SessionIndex="_bf9c623d-cc20-407a-9a59-c2d0aee84d12">
<AuthnContext>
<AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>

Comparing OAuth and SAML

  • The format is the most significant difference between the two. While OAuth uses JSON (JavaScript Object Notation), SAML uses XML (Extensible Markup Language).
  • OAuth is recommended for mobile apps due to its successive use of API calls.
  • SAML is used as SSO for enterprises, while OAuth is used for API authorisation.
  • The main assumption of OAuth is delegating authorisation and it should not be used for authentication. SAML, on the other hand, can handle both these processes.

OpenID as an Alternative

An architecture of distributed authentication and distribution of users identities in web services, OpenID solves the problem of distributing identity parameters of an user (their data) between numerous web services. Instead of creating independent accounts in a number of services, the user creates only one account on an OpenID server, storing their personal data there and obtaining an OpenID identifier.

Sources:

https://zaufanatrzeciastrona.pl/post/zarzadzanie-tozsamoscia-w-chmurze-oraz-porownanie-standardow-saml-openid-oauth/
https://sekurak.pl/oauth-2-0-jak-dziala-jak-testowac-problemy-bezpieczenstwa/
https://pl.wikipedia.org/wiki/OAuth_2.0#SAML_vs._OAuth
https://pl.wikipedia.org/wiki/OpenID
https://learn.microsoft.com/pl-pl/azure/active-directory/develop/single-sign-on-saml-protocol
https://medium.com/l-r-engineering/oauth2-in-android-authorization-code-flow-ffc4355dd473
https://www.lightsaml.com/LightSAML-Core/Cookbook/How-to-make-AuthnRequest/
https://developer.android.com/training/id-auth/authenticate
https://www.oracle.com/pl/security/cloud-security/what-is-saml/
https://www.manageengine.com/pl/self-service-password/integracja-saml-sso-active-directory.html
https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
https://auth0.com/blog/complete-guide-to-angular-user-authentication

Author: Michał Krawiec, Senior Technical Consultant | Software Developer

Follow us!
www.linkedin.com/company/convistapoland
Blog | Convista

Über ConVista Consulting Sp. z o.o.

Convista is one of the leading consultancies for business transformation. It offers comprehensive and reliable support to its clients in developing and implementing new business processes and crafting end-to-end solutions for SAP as well as IT projects.

In collaboration with its clients, Convista manages complex challenges by combining many years of industry and technology experience and profound expertise. With over two decades of experience, Convista has established itself as a trusted partner for customers operating in the insurance, industry, healthcare, and energy sectors, enabling them to adapt to the demands of an ever-evolving digital world.

IT blog. For IT people. Powered by Convista Poland.

Convista Poland’s blog is the ultimate hub for IT enthusiasts packed with cutting-edge IT articles crafted by Convista´s skilled and experienced employees specializing in Java, iOS, Android, and ABAP, making sure you get top-notch content on these subjects. What makes it truly priceless? It’s the hands-on experience of creators, who actively work on corporate projects every day. They are always pushing the boundaries of their skills, eager to share knowledge, and constantly motivated to explore new frontiers.

Concerning the blog topics and valuable content, one is able to stay up-to-date with the latest IT trends and advancements as well as the opportunity to join a community of like-minded individuals passionate about technology.

Firmenkontakt und Herausgeber der Meldung:

ConVista Consulting Sp. z o.o.
Ul. Powstańców Śląskich 7A
PL53-332 Wrocław
Telefon: +49 (221) 88826-0
Telefax: +49 (221) 88826-199
https://www.convista.pl

Ansprechpartner:
Wioleta Patkowska
HR Manager
E-Mail: wioleta.patkowska@convista.com
Für die oben stehende Pressemitteilung ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel