OAuth2 Authentication with AngularJS

OAuth2 with AngularJS
Bix Labs

Topics
Introduction
Authorization vs Authentication
SSL (Secure Sockets Layer)
Authentication Evolution
Basic Authentication
Form Based Authentication
Failed Attempts
OAuth2 Introduction
What is OAuth 2.0

Authorization vs Authentication
Authentication verifies who you are
In terms of web apps, very crudely speaking, authentication is when you check login credentials to see
if you recognize a user as logged in, or decide to let it log in or not.
Authorization verifies what you are authorized to do.
In terms of web apps, is when you look up in your access control whether you allow the user to edit,
delete or create content or execute specific actions or navigate to specific pages, depending on
their current user or role permissions.

Secure Sockets Layer
SSL (Secure Sockets Layer) is a standard security technology for establishing an
encrypted link between a server and a client—typically a web server (website) and
a browser; or a mail server and a mail client (e.g., Outlook).
SSL allows sensitive information such as credit card numbers, social security
numbers, and login credentials to be transmitted securely.
Normally, data sent between browsers and web servers is sent in plain text—leaving
you vulnerable to eavesdropping.
If an attacker is able to intercept all data being sent between a browser and a web
server they can see and use that information.

Secure Sockets Layer (II)
Technically, SSL is a security protocol, it determines variables of the encryption for
both the link and the data being transmitted.
All browsers have the capability to interact with secured web servers using the SSL
protocol. However, the browser and the server need what is called an SSL
Certificate to be able to establish a secure connection.
SSL Certificates have a key pair: a public and a private key. These keys work
together to establish an encrypted connection. The certificate also contains what
is called the “subject,” which is the identity of the certificate/website owner.

Secure Sockets Layer (III)
When a browser attempts to access a website that is secured by SSL, the browser
and the web server establish an SSL connection using a process called an “SSL
Handshake”.
Essentially, three keys are used to set up the SSL connection: the public, private,
and session keys. Anything encrypted with the public key can only be decrypted
with the private key, and vice versa.
Because encrypting and decrypting with private and public key takes a lot of
processing power, they are only used during the SSL Handshake to create a
symmetric session key. After the secure connection is made, the session key is
used to encrypt all transmitted data.

Secure Sockets Layer (IV)
1. Browser connects to a web server (website) secured with SSL (https).
Browser requests that the server identify itself.
2. Server sends a copy of its SSL Certificate, including the server’s public
key.
3. Browser checks the certificate root against a list of trusted CAs and that
the certificate is unexpired, unrevoked, and that its common name is valid
for the website that it is connecting to. If the browser trusts the certificate, it
creates, encrypts, and sends back a symmetric session key using the
server’s public key.
4. Server decrypts the symmetric session key using its private key and sends
back an acknowledgement encrypted with the session key to start the
encrypted session.

Authentication evolution
Over the years

Basic Authentication
In the beginning, the web was all about open access.
But as time went on, the Web became about "e-commerce," and e-commerce
required security.
SSL matured to ensure that sensitive traffic was encrypted all the way from the client
to the server and back, and various schemes emerged to allow user
authentication.
The oldest format for web authentication is HTTP Basic Authentication.
This is what you get when you visit a web site and a little browser window pops up
requesting a username and password.

Basic Authentication (2)
From a web design perspective, HTTP Basic Authentication has a big disadvantage
in that it's implemented entirely by the browser, and can't be customized for each
site.
As the quality of graphic design improved on the web, designers soon realized that
they didn’t want a generic little grey box on the screen, but a carefully-designed
login page.
The combination of HTTP Basic and HTML just didn't allow this. :-(

Form Based Authentication
The next evolution step, caused by the desire to have beautiful login web pages was the
introduction of what is called Form Based Authentication.
This is what the vast majority of secure web sites use today.
As a user, you visit a web page that prompts you for a username and password.
If authentication is successful, then under the covers you are granted a unique cookie, which
your web browser sends with each subsequent request.
As a user you never see this -- it just looks like you logged in and now the site works.
Both Basic and form-based authentication rely on SSL to create an encrypted tunnel between
the client and server.

Form Based Authentication (II)
Fortunately, SSL protects against this very well.
However, developers sometimes neglect to use it, users neglect to ask for it and sometimes
the traffic travels over unencrypted links behind the firewall of a large network.

Failed Attempts
The web community attempted to counter this using HTTP Digest authentication.
It encrypts the password using a one-way hash so it's impossible to reverse-engineer even
if SSL is not used -- but it still must be implemented by the browser and can't be
designed in to a nice UI.
It never became popular enough.
For a higher level of security, SSL has long supported two-way authentication.
This requires that individual end users, request digital certificates for each site they plan to
visit and install those signatures on their browsers.
The overhead of issuing PKI credentials to end users was enormous and this never
became popular enough either.

What is OAuth 2.0
Authorization framework
Next evolution of the OAuth protocol
Enables apps to obtain limited access to user accounts in other services
Delegates authentication to the service that hosts the user account
Authorizes third-party apps to access the user account
Focuses on client developer simplicity
Provides different approaches and guidelines to use while connecting from

Roles
Resource Owner
User who authorizes an application to access their account
Client
Application that wants to access the user's account.
To access it, it must be authorized by the user.
The authorization must be validated by the API.
Resource Server
Hosts the protected user accounts.

Registering your App
Before using OAuth with your application,
you must register your application
with the service.
Done through a registration form in the
Developer or API service Site
One must provide:
Application Name
Application Website
Redirect URI or Callback URL
After our App is registered, the service
will give us Client Credentials

Client Id, Client Secret and Redirect URI
Client Id
Publicly exposed string that is used by the service API to identify the application.
Used to build authorization URLs that are presented to users.
Client Secret
Used to authenticate the identity of the application to the service API.
Must be kept private between the application and the API.
If a deployed app cannot keep the secret confidential, such as Javascript or native apps, then the secret
is not used.
Redirect URI
The service will only redirect users to a registered URI, which helps prevent some attacks.
Any HTTP redirect URIs must be protected with TLS security
So the service will only redirect to URIs beginning with "https"
This prevents tokens from being intercepted during the authorization process.

Abstract Protocol Flow 1. The application requests authorization to
access service resources from the user
2. If the user authorized the request, the
application receives an authorization
grant
3. The application requests an access
token from the authorization server (API)
by presenting authentication of its own
identity, and the authorization grant
4. If the application identity is authenticated
and the authorization grant is valid, the
authorization server (API) issues an
access token to the application.
Authorization is complete.
5. The application requests the resource
from the resource server (API) and
presents the access token for
authentication
6. If the access token is valid, the resource
server (API) serves the resource to the
application

Abstract Protocol - Obtain authorization
To request an access token, the client obtains authorization from the resource owner.
The authorization is expressed in the form of an authorization grant.
The client uses an authorization grant to request the access token.
As we will see in the next slide, there are 4 possible authorization grant types.

Authorization Code
Used with server-side Applications
Implicit
Used with Mobile Apps or Web Applications
Resource Owner Password Credentials
Used with trusted Applications, such as those owned by the service itself
Grant Types and their usage

Authorization code grant
Used to obtain both access tokens and refresh tokens.
Optimized for confidential clients.
It’s the most commonly used because it is optimized for server-side apps
Server-side, the source code is not publicly exposed (notice the difference with client apps)
And so the Client Secret confidentiality can be maintained

Authorization code grant (2)
Generic Steps

Specific Steps

1 & 2 - User Authorization Request & User Authorizes Application
From the Application Front End to the Auth Server
1. The user clicks the link or presses a button in the web browser.
2. Client constructs the request URI to send to the Auth Server, Server API
Uses the following parameters:
client_id: the application's client ID
redirect_uri: where the service redirects the user-agent after an authorization code is granted
response_type: “code” specifies that your application is requesting an authorization code grant
scope: specifies the level of access that the application is requesting, for example: read, write, and so on.
3. They are redirected to a special page in the Auth Server, to authenticate them

Example URI:
https://accounts.google.com/o/oauth2/auth?client_id=1046506418225-
dgpu1935ji53o196us39t959oknt7s2h.apps.googleusercontent.com&redirect_uri=http://localhost:9000/&response_typ
e=code&scope=read
4. Then they must first log in to the service, to authenticate their identity.
5. If they accept, they are prompted by the Auth Server to authorize or deny our
Application access request to their accounts

3 - Authorization Response (Code Grant)
From the Auth Server to the Application Backend Server
● If the user clicked the Authorize Application in the previous step ...
● The Auth Server redirects the user-agent to the application redirect URI
○ This URL was set, when we registered our App, it is called the callback URL
○ The Auth Server also issues an authorization code and delivers it to the client app.
● This HTTP response uses the following parameters
○ code: MUST expire shortly after it is issued to mitigate the risk of leaks
○ state: (Optional) required if the "state" parameter was present in the client auth request
● Example URI:
http://localhost:9000/callback?code=SplxlOBeZQQYbYS6WxSbIA

4 - Access Token Request
From the Application Backend Server, to the Auth Server
● A secure component, such as the Application Server Backend, requests an
Access Token to the Auth Server.
○ It sends the authorization code, along with other app credentials against the auth server:
■ Client Id
■ Client Secret
○ Optionally, depending on the OAuth server, we may also receive a Refresh Token.

4 (II) - Access Token Request
● This HTTP POST request uses the following parameters:
○ grant_type: Value MUST be set to "authorization_code".
○ code: The authorization code received from the authorization server.
○ client_id: the application's client ID.
○ client_secret: the application's client secret.
○ redirect_uri: where the service redirects the user-agent after an authorization code is granted.
Example URI:
https://accounts.google.com/o/oauth2/token?grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&cli
ent_id=1046506418225-

5 - Access Token Grant (Response)
From the the Auth Server to the Application Backend Server
● If the access token request is valid and authorized, the authorization server issues
an access token and optional refresh token.
● The optional refresh token can be used, to refresh the access token, without
having to repeat the whole process to receive a new one.
Example of a successful response:
{ "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"bearer", "expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" }

Implicit grant
Used for mobile apps and web applications, where the client secret confidentiality is not
guaranteed.
Similar to an authorization code grant, except the access token is returned to the client
application already after the user has finished the authorization.
The access token is returned when the browser is redirected to the redirect URI.
The implicit grant type does not include client authentication, and relies on the presence
of the resource owner and the registration of the redirection URI.
Because the access token is encoded into the redirection URI, it may be exposed to the
resource owner and other apps residing on the same device.

Implicit grant (2)
The access token is accessible in the user agent, or native application, which is
why this is not secure.
This because the access token is not stored securely on a web server.
The access token is short lived, because if it is intercepted, the hacker can only use
it for a short time.
That’s why the protocol itself does not support the issuance of refresh tokens.
The client application can only send its Client ID to the authorization server.
If the client were to send its Client Secret too, the client secret would have to be
stored in the user agent or native application too. That would make it vulnerable
to hacking.

Implicit grant (3)
Generic Steps
● The user is asked to authorize the application, then the authorization server passes the
access token back to the user-agent, which passes it to the application.

Implicit grant (4)
Specific Steps

Implicit grant (5)
From the Application Front End to the Auth Server
1. The user clicks the link or presses a button in the web browser.
2. Client constructs the request URI to send to the Auth Server, Server API
(Just like in the authorization code grant, except it is now requesting a token
instead of a code.)
Uses the following parameters
client_id: the application's client ID.
redirect_uri: where the service redirects the user-agent after an access token is granted.
response_type: “token” specifies that your application is requesting an access token.
scope: specifies the level of access that the application is requesting, for example: read, write, and so on.

Implicit grant (6)
From the User Agent (Web Browser) to the Auth Server
3. They are redirected to a special page in the Auth Server, to authenticate them
4. They must first log in to the service, to authenticate their identity.
5. If they accept, they are prompted by the Auth Server to authorize or deny our
Application access request to their accounts

Implicit grant (7)
3 - Redirect URI with Access Token
From the Auth Server to the User Agent (Web Browser)
● If the user clicked the Authorize Application in the previous step ...
● The Auth Server redirects the user-agent to the application redirect URI
○ This URL was set, when we registered our App, it is called the callback URL
○ The Auth Server also issues an access token and delivers it to the user agent, as a parameter in the
callback URI.
Example callback URI:
http://localhost:9000/callback#token=2YotnFZFEjr1zCsicMWpAA

Implicit grant (8)
3 - Redirect URI with Access Token (II)
● This HTTP response uses the following parameters
○ access_token: The access token issued by the authorization server.
○ token_type: The type of the token issued. Value is case insensitive.
○ expires_in: The lifetime in seconds of the access token.
○ scope: Optional if identical to the scope requested by the client
○ state (Optional): It is required if the "state" parameter was present in the client authorization request.

Implicit grant (9)
4 - Follow Redirect URI (Retain Token)
From the User Agent (Web Browser) to the Application Front End
● The user-agent follows the redirect URI but retains the access token.

Implicit grant (10)
5 - Send Token Extract Script
From the Application Front End to the User Agent (Web Browser).
● The application returns a webpage that contains a script that can extract the
access token from the full redirect URI that the user-agent has retained.
● In AngularJS we can do this in the config function of a module, by adding
javascript code in the $routeProvider behavior, when a route of the form of
/callback is detected, as we will see afterwards.

Implicit grant (11)
6 - Access Token Passed to Application
From the User Agent (Web Browser) to the Application Front End.
● The user-agent executes the provided script and passes the extracted access
token to the application.
● Now the application is authorized! It may use the token to access the user's
account via the service API.

Using Implicit Grant with AngularJs
● In order to be able to log in to a third party server such as Google or Facebook,
we have to first register our App in the Google or Facebook Developer Site and
then program two things in different parts of the AngularJs Application:
1. Register the Application name, callback URI and receive a Client Id, that identify our app.
2. In the AngularJs app, we have to implement the user redirection to the OAuth 2 Authentication
Server (Facebook, Google) and then retrieve the access token and store it somewhere.
3. Also, in the AngularJs app, we have to implement the way we use the access token, in order
to authenticate the logged in user via OAuth2, against a REST Web Api, for example.
● We can find a sample project of how to do this here:
https://github.com/bixlabs/oauth-angular-client

Using Implicit Grant with AngularJs (2)
Step 1, as discussed previously in the
“Registering your App” slide.
Done through a registration form in the
Developer or API service Site
One must provide:
Application Name
Application Website
Redirect URI or Callback URL
After our App is registered, the service
will give us Client Credentials
Client Identifier (Client ID)

● Step 2: Implement the user redirection to the OAuth 2 Authentication Server
(Facebook, Google) and then retrieve the access token and store it somewhere.
First, we have to add authentication redirection to the resource owner, in a login function, called from a link or button:
angular.module('app')
.controller('MainCtrl', function ($scope) {
$scope.login=function() {
var client_id="your client id";
var scope="email";
var redirect_uri="http://localhost:9000";
var response_type="token";
var
url="https://accounts.google.com/o/oauth2/auth?scope="+scope+"&client_id="+client_id+"&redirect_uri="+redirect_uri+"&respons
e_type="+response_type
window.location.replace(url);
};

● Step 2 (continuation):
Then, should the authentication be successful, we have to add route configuration in order to obtain and parse
the authentication token:
angular.module('app', [])
.config(function ($routeProvider) {
$routeProvider
.when('/access_token=:accessToken', {
template: '',
controller: function ($location, $rootScope) {
/* Obtain, parse and split the Query String */
var hash = $location.path().substr(1);
var splitted = hash.split('&');
var params = {};
….
….
/* Get the access token parameter and save
it somewhere, like rootscope */
for (var i = 0; i < splitted.length; i++) {
var param = splitted[i].split('=');
var key = param[0];
var value = param[1];
params[key] = value;
$rootScope.accesstoken = params;
} // Finally redirect the user to the main view
$location.path("/main");
}})});

● Step 3:
We can use the transformRequest property of $http to modify every subsequent request made and append
your token automatically.
angular.module('myApp',myDependanciesArray) .config(['$routeProvider', function($routeProvider) {
$routeProvider.when('/entity/:id', {templateUrl: 'partials/template.html', controller: 'EntityCtrl'}); })
.run(['$rootScope', '$injector', function($rootScope, $injector) {
$injector.get("$http").defaults.transformRequest = function(data, headersGetter) {
/* Inject Authorization header including access token for each http response */
if ($rootScope.oauth) headersGetter()['Authorization'] = 'Bearer ' +$rootScope.oauth.access_token;
if (data) { return angular.toJson(data); }
};
}
});

● Step 3 (continuation):
In order to deal with Token Expiracy or revokation, we’ll have to intercept those HTTP responses from the Web
API that include a 401 Unauthorized - error status, and then do one of both things:
1) Resolution without taking into account that many requests may have failed
a) Ask for an access token to the Authorization Server API again
b) Re-send the http request that failed with the 401 Error Status again, with the newly
acquired access token.
2) Resolution, taking into account that many requests have failed and we want to resend them in order
a) Send all the failing http request with 401 error to a queue
b) Ask for an access token to the Authorization Server API

References
● https://developers.google.com/identity/protocols/OAuth2
● https://github.com/bixlabs/oauth-angular-client
● http://tools.ietf.org/html/rfc6749
● http://apigee.com/about/blog/technology/short-history-api-authentication-and-where-its-going-http-basic-oauth-20
● https://www.digicert.com/ssl.htm
● http://www.cyberciti.biz/faq/authentication-vs-authorization/
● https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
● http://engineering.talis.com/articles/elegant-api-auth-angular-js/

OAuth2 Authentication with AngularJS

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a OAuth2 Authentication with AngularJS

Similar a OAuth2 Authentication with AngularJS (20)

Último

Último (20)

OAuth2 Authentication with AngularJS

Notas del editor