Authentication
What are the authentication mechanisms used in web applications?
Cookie-Based authentication
This authentication mechanism is the easiest to implement if the server stack supports it. It’s non-intrusive and may require bare minimum changes to the Angular application. Cookie-based authentication involves setting the browser cookie to track the user authentication session.
A cookie is just an item in a dictionary. Each item has a key and a value. For authentication, the key could be something like ‘username’ and the value would be the username. Each time you request a website, your browser will include the cookies in the request, and the host server will check the cookies. So authentication can be done automatically like that.
To set a cookie, you just have to add it to the response the server sends back after requests. The browser will then add the cookie upon receiving the response.
There are different options you can configure for the cookie server-side, like expiration times or encryption. An encrypted cookie is often referred to as a signed cookie. The server encrypts the key and value in the dictionary item, so only the server can make use of the information. So then the cookie would be secure.
A browser will save the cookies set by the server. In the HTTP header of every request the browser makes to that server, it will add the cookies. It will only add cookies for the domains that set them. Example.com can set a cookie and also add options in the HTTP header for the browsers to send the cookie back to subdomains, like sub.example.com. It would be unacceptable for a browser to ever sends cookies to a different domain.
Token-based authentication
The general concept behind a token-based authentication system is simple. Allow users to enter their username and password to obtain a token that allows them to fetch a specific resource — without using their username and password. Once their token has been obtained, the user can offer the token — which offers access to a specific resource for some time — to the remote site.
In other words: add one level of indirection for authentication — instead of having to authenticate with username and password for each protected resource, the user authenticates that way once (within a session of limited duration), obtains a time-limited token in return, and uses that token for further authentication during the session.
Advantages are many — e.g., the user could pass the token, once they’ve obtained it, on to some other automated system which they’re willing to trust for a limited time and a limited set of resources, but would not be willing to trust with their username and password (i.e., with every resource they’re allowed to access, forevermore or at least until they change their password).
If anything is still unclear, please edit your question to clarify WHAT isn’t 100% clear to you, and I’m sure we can help you further.
Third-party access (OAuth, API-token)
OAuth and OAuth 2.0 are widely used authentication protocols that alert resource providers (e.g. Facebook, Twitter, Google, Microsoft, etc.) every time resource owners permit third parties to run HTTP applications without exposing user passwords. In this blog, we will discuss how OAuth 2.0 can be used to support the authentication of business-critical HTTP applications with Google and cloud services. I will specifically focus on my team’s direct experience in implementing OAuth 2.0 for one of the eInfochips clients, a leading smart home automation player. The client has an ecosystem of partners who need to be authorized to access HTTP services to manage smart home appliances such as water sprinklers, refrigerators, thermostats, indoor lighting, etc.
OpenID
OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol, which allows clients to verify the identity of an end-user based on the authentication performed by an authorization server or identity provider (IdP), as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.
OpenID Connect is an increasingly common authentication protocol: when an app prompts you to authenticate using your Facebook or Google+ credentials, the app is probably using OpenID Connect.
OpenID Connect allows a range of clients, including web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users.
One Login provides a custom connector option that makes it easy to configure your OpenID Connect-enabled app to use One Login as the Identity Provider (IdP) in an OpenID Connect flow.
SAML
Before jumping into the technical jargon, let’s look at an example that demonstrates what SAML is and why it’s beneficial.
You just started working at a new company, Wizova. They’ve given you a work email address and access to a dashboard. Once you sign in to this dashboard, you’re presented with the icons of all of the external services the company uses: Salesforce, Expensify, Jira, AWS, and more.
You click on the Salesforce icon, some magic happens in the background, and before you know it, you’re signed into Salesforce without ever entering any credentials!
As you might have guessed, the “magic” was SAML in action. So what’s going on here?
SAML stands for Security Assertion Markup Language. It is an XML-based open-standard for transferring identity data between two parties: an identity provider (IdP) and a service provider (SP).
Identity Provider — Performs authentication and passes the user’s identity and authorization level to the service provider.
Service Provider — Trusts the identity provider and authorizes the given user to access the requested resource.
In the scenario above, the identity provider would be the IdP that Wizova uses, Auth0. The service provider would be Salesforce. The Wizova employee signs into the Wizova dashboard with Auth0. They click on the Salesforce icon, and Salesforce recognizes that the user wants to log in via SAML. Salesforce sends the employee back to Auth0 with a SAML Request that asks Auth0 to authenticate the user. Since the employee has already authenticated with Auth0, Auth0 verifies the session and sends the user back to Salesforce with a SAML Response. Salesforce checks this response, and if it looks good, the employee is granted access!
