Comparing Authentication and Authorization
This is a large and somewhat confusing topic in software engineering. It doesn't help that we often abbreviate both terms to "auth", so first an explanation in plain English:
Authentication: Are you who you say you are.
Authorization: What you are allowed to do.
It is useful to have the above one-liners in mind when thinking about these terms.
Authentication is the act of confirming a claim to be true, authentic, real, genuine. E.g. A person at airport claims to be Kye Yeung with a passport. The security guard authenticates this claim.
Authorization is the act of giving permission to access resources. E.g. My nephew asks if he can play video games for an hour, I can authorize/give him permission to do so or not.
This article will discuss a few popular internet security technologies but is by no means exhaustive.
The receiving backend will decode and authenticate these credentials and either return a 200(OK) response or a 401 (Unauthorized).
There are multiple use cases for basic auth. For instance, A simple web app could implement a forms login using basic auth as a standard way to send the credentials to a backend. If authenticated a session cookie could be dropped into the browser while the user is logged-in.
Another use case could be a backend system making requests to a third-party API. The API can use the credentials to give limited access to specific endpoints. For example, external client credentials would be authorized to use the public API of a service. Whereas internal admin credentials would be additionally authorized to use private admin endpoints. I have created a simple service authentication_basic to illustrate this.
It's interesting to note that the header is Authorization and not Authentication. This shows the closeness of the two processes and why they are so often confused with either other. In reality, both processes would be happening. First, the service authenticates the credentials (is the username and password pair valid), then authorises the authenticated user for using the endpoint (are you allowed to use this endpoint).
Authentication: Are you who you say you are.
Authorization: What you are allowed to do.
It is useful to have the above one-liners in mind when thinking about these terms.
Authentication is the act of confirming a claim to be true, authentic, real, genuine. E.g. A person at airport claims to be Kye Yeung with a passport. The security guard authenticates this claim.
Authorization is the act of giving permission to access resources. E.g. My nephew asks if he can play video games for an hour, I can authorize/give him permission to do so or not.
This article will discuss a few popular internet security technologies but is by no means exhaustive.
Basic HTTP Authentication
Basic HTTP authentication, often abbreviated to "basic auth", is a protocol that requires client requests to send a base64 encoded username and password in an Authorization HTTP header. The following example contains the encoded username: user and password: password.
curl -X GET http://localhost:8080/api/add -H 'Authorization: Basic dXNlcjpwYXNzd29yZA=='
The receiving backend will decode and authenticate these credentials and either return a 200(OK) response or a 401 (Unauthorized).
There are multiple use cases for basic auth. For instance, A simple web app could implement a forms login using basic auth as a standard way to send the credentials to a backend. If authenticated a session cookie could be dropped into the browser while the user is logged-in.
Another use case could be a backend system making requests to a third-party API. The API can use the credentials to give limited access to specific endpoints. For example, external client credentials would be authorized to use the public API of a service. Whereas internal admin credentials would be additionally authorized to use private admin endpoints. I have created a simple service authentication_basic to illustrate this.
It's interesting to note that the header is Authorization and not Authentication. This shows the closeness of the two processes and why they are so often confused with either other. In reality, both processes would be happening. First, the service authenticates the credentials (is the username and password pair valid), then authorises the authenticated user for using the endpoint (are you allowed to use this endpoint).
Advantages
- Simple to implement backend.
- Simple client integration and testing. Clients can use a simple cURL.
Disadvantages
- The user has to invent and remember another username and password pair.
- The service would no longer be a single responsibility application.
- Security is a cross-cutting concern for an organisation and this style leads to duplication amongst multiple backend services.
- Data protection compliance (GDPR) considerations. E.g. Hashing passwords in DB, not logging sensitive data etc.
- The service would no longer be a single responsibility application.
- Security is a cross-cutting concern for an organisation and this style leads to duplication amongst multiple backend services.
- Data protection compliance (GDPR) considerations. E.g. Hashing passwords in DB, not logging sensitive data etc.
- The organisation can potentially become a target for attack to gain access to credentials.
OAuth2
OAuth2 is a framework for delegated authorization over the internet. Every time you see the following style of pop-up on the internet, you are using OAuth2.
fig 1. OAuth2 approval pop-up in trusted www.facebook.com domain. OAuth2 roles: client(Simulator app), authorization server(Facebook), resource service(Facebook photos API), requested scopes(public profile, friends list and photos).
Via OAuth2 a user will delegate authority to an app to gain access to some resource he owns, for example, a user has a photos app that adds Instagram style filters and wants to give the app access to his photos on an existing social media account.
If the app did not integrate with OAuth2 it would have two choices, 1. ask the user to upload the photos into the app (duplication of resource, app has more complexity, a little bad) or 2. ask user give account credentials of social media account (giving up your credentials, very bad).
With OAuth2 the app can initiate the following authorization code flow instead:
fig2. OAuth2 authorization code flow
1. The user (resource owner) selects a source of photos in the app (client), Facebook, Google etc.
2. The app makes an authorization request including the scopes (read photos) required with a redirect URL to e.g. Facebook (authorization server) via the Authorization Endpoint.
3. The user is presented with a pop-up in the trusted www.facebook.com domain and logs in.
4. The user is presented with a consent screen to authorize the app to access the photos and agrees.
5. Facebook makes a callback to the redirect URL sending an Authorization Code on an insecure front-channel.
6. The app swaps the Authorization Code for an Access Token + Refresh Token by sending the Authorization Code + Client Secret to Facebook on a secure back-channel. Via the Token Endpoint.
7. The app can now use the Access Token and make requests to the Facebook photos API (resource server).
7. The app can now use the Access Token and make requests to the Facebook photos API (resource server).
fig3. OAuth2 Implicit flow
Other OAuth2 flows exist which suit different situations. For example, if a secure back-channel is not available the implicit flow would be used which skips the swapping of the Authorization Code by giving the Access Token immediately in the callback (step 5) and the Token Endpoint is never called.
It is interesting to note that the API request that includes the Access Token is sent using the same Authorization HTTP header as basic auth. However, rather than having the basic scheme it uses the bearer token scheme. This is why sometimes the Access Tokens are called bearer tokens.
Authorization: Bearer cn389ncoiwuencr
It is tempting to use the term "social login" to describe OAuth2, but that's not strictly correct since the only use case OAuth2 is meant to serve is delegated authorization, a closely related technology OpenID Connect, which is responsible for authentication use cases fits this term better.
Advantages
- Data protection not the concern of the app. The app can be a single responsibility application.
- The user doesn't have to invent another username and password pair.
- User trust of existing social account, explicit permissions granted.
- Widely adopted in the industry.- The user doesn't have to invent another username and password pair.
- User trust of existing social account, explicit permissions granted.
Disadvantages
- More involved implementation than Basic HTTP authentication for the backend.
- Less easy clients to integrate and test, cannot do a simple cURL to access the resource.
- Unfortunate naming "auth" leads to confusion of its purpose, it is in fact delegated authorization which requires an intermediate login step.
- No standard way of using OAuth2 for the authentication use case, the industry had bespoke solutions. OpenID Connect was created to solve this issue.
OpenID Connect
OpenID Connect is a simple identity layer on top of the OAuth2, i.e. it solves the authentication use case that OAuth2 had no standard way of doing.
An OAuth2 authorization server that supports OpenID Connect is known as an OpenID Provider (OP). An OP will return an additional ID Token if the initial authorization request contained the known scope "openid".
fig4. ID token in JTW format
The ID Token (in JWT format) is the primary extension to OAuth2 which can be decoded by the app revealing a series of mandatory claims. E.g. iss: Issuer Identifier, sub: Subject Identifier, exp: expiry time of ID Token etc.
The Access Token may also be used to request additional standard claims in JSON format via the UserInfo endpoint. E.g. given_name, family_name, email etc.
An OAuth2 authorization server that supports OpenID Connect is known as an OpenID Provider (OP). An OP will return an additional ID Token if the initial authorization request contained the known scope "openid".
fig4. ID token in JTW format
The ID Token (in JWT format) is the primary extension to OAuth2 which can be decoded by the app revealing a series of mandatory claims. E.g. iss: Issuer Identifier, sub: Subject Identifier, exp: expiry time of ID Token etc.
The Access Token may also be used to request additional standard claims in JSON format via the UserInfo endpoint. E.g. given_name, family_name, email etc.
Advantages
- Is built on top of preexisting, widely adopted OAuth2 technology.
- The industry is moving towards OpenID Connect. Many libraries in multiple languages available for integration.
- A known migration path from OAuth2.
- New authentication technologies can be offered by the OpenID Identity Providers, 2-factor device biometrics such as finger print etc. Integration to the app is seamless.
- New authentication technologies can be offered by the OpenID Identity Providers, 2-factor device biometrics such as finger print etc. Integration to the app is seamless.
- Handles different authentication use cases in a standard way including:
> Simple login
> Single sign-on: session management
> Mobile app login: standard library AppAuth integration.
> Simple login
> Single sign-on: session management
> Mobile app login: standard library AppAuth integration.
Disadvantages
- Often confused as a replacement for OAuth2, it is a complementary technology that handles different use cases.
- Is built on top of preexisting, widely adopted OAuth2 technology, which may be confusing.
- Is built on top of preexisting, widely adopted OAuth2 technology, which may be confusing.
Resources
- RFC 7617 - 'Basic' Scheme
- RFC 6750 - 'Bearer' Token scheme
- RFC 7235 - HTTP Authorization header
- RFC 6749 - OAuth 2.0
- OpenID Connect
- JSON Web Token
- https://www.youtube.com/watch?v=996OiexHze0
- RFC 6750 - 'Bearer' Token scheme
- RFC 7235 - HTTP Authorization header
- RFC 6749 - OAuth 2.0
- OpenID Connect
- JSON Web Token
- https://www.youtube.com/watch?v=996OiexHze0
Comments
Post a Comment