Posted on

Basics for Authorization and Authentication in an WebApp

In order to implement a minimum but strong  security in an app is required to have present how we are going to authenticate the users and what they will be able to see and manage.

The research that has been done drove me to the next:

  • We need an authentication layer: Only registered users will be able to access to the app
  • We need an authorization layer: Depend on the role, the user will be able to see only the menus assigned

For implementing this requirements during the research we realized that we can find several ways of implementing this two specifications:

  • SAML or OAuth 2.0 –> (Authorization)
  • Spring Security (contains OAuth2) + XAMCL + Identity Provider with OpenID Connect (OIDC based on JWT)
  • Spring Security (contains OAuth2) + Identity Provider with OpenID Connect (OIDC based on JWT)
  • OAuth + Identity Provider with OpenID Connect (OIDC based on JWT)

Following these points I am going to explain the conclusions:

  • SAML vs OAuth 2.0

SAML:

  • Security Assertion Markup Language
  • XML-based open standard for exchanging authentication and authorization data between parties
  • Requires Digital Signature
  • SAML token contains the user identity information (because of signing).
  • Specifically designed for SSO (Single Sign-ON)
  • Entities involved:
    1. The principal or Client (user): This is how the user is interacting with the Resource Server, like a web app being server through a web browser.
    2. Identity Provider (IdP) – Authorization Server: This is the server that owns the user identities and credentials. It’s who the user actually authenticates with.
    3. Service Provider (SP) – Resource Server: This is the web-server you are trying to access information on.

OAuth 2.0:

  • Protocol for Authorization
  • Has the benefit of being recent and takes into consideration how the world has changed in the past eight years. Mobile devices and native applications are prevalent today in ways that SAML could not anticipate in 2005.
  • Not id_token (provided by OIDC), YES access token
  • Communication between IdP and SP is done over HTTP Redirects with the token information provided as query parameters
  • It does not assume the Client is a web-browser whereas the default SAML Web Browser SSO Profile does
  • Not requires Digital Signatures by Default – This could be a disadvantage because of security but it is cover by a top framework/library
  • It is more standardized
  • It can invalidate an access token on the IdP and disable it from further access to the SP
  • Web or mobile sign-in flow
  • Provides specific authorization flows for: Web, mobile, API access management, posting in someone wall, IoT services…
  • Entities:
    1. Resource Server (Service Provider) – This is the web-server you are trying to access information on.
    2. Client – This is how the user is interacting with the Resource Server. This could be a browser-based web app, a native mobile app, a desktop app, a server-side app.
    3. Authorization Server (Identity Provider) – This is the server tha owns the user identities and credentials. It’s who the user actually authenticates and authorizes with.

Here the diagrams of SAML and OAuth2.0

 

If what you want to develop is a WebApp, OAuth will fit in this use case as it is a simpler and more standardized solution which covers all the current needs and it is not required to have a workaround in some processes as there would be with SAML.

Once we reached to this point, then next step is to complement the lacks of OAuth 2.0, fortunately, this was easy to choose inasmuch as a top layer has being implemented over OAuth 2.0 in order to cover those lacks, this is OpenID Connect.

Open ID Connect (OIDC):

  • It’s a authentication protocol
  • It is a secure mechanism for an app to contact an IdP, get some user details, and return them back to the app in a secure way
  • Standard for IdP (Identity Provider)
  • Easy to consume identity tokens: The id_token which is the User’s identity comes encoded in a secure JSON Web Token (JWT)
  • Based on the OAuth 2.0 protocol: Clients use OAuth 20.0 flows to obtain ID tokens. OAuth 2.0 also means one protocol for authentication and authorization (obtaining access tokens)
  • Simplicity: Can be integrated with basic apps and also security options to match demanding enterprise requirements.
  • RESTful/JSON HTTP focus
  • It has client_id, client_secret, redirect_uri which are stored by the IdP
  • It allows the user to decide what personal information is willing to give to an app
  • Designed to support beside of Web-based applications, also support native apps and mobile applications
  • Optional workflows:
    1. Implicit workflow (Only client side)
    2. Authentication Flow (Only for backend)
    3. Hybrid Flow (back and front end)
  • Entities:
    1. OpenID Provider (referred also as Authorization server)