securitywithsoa: September 2016

Introduction

When it comes Authentication you may heard about many protocols. SAML, OpenID, WS-Federation passive are some of them. Now a days OpenID Connect is the most emerging authentication protocol and it has been built on top of OAuth 2.0 protocol. OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users.
OpenID Connect contains bunch of specifications namely

Core – Defines the core OpenID Connect functionality: authentication built on top of OAuth 2.0 and the use of Claims to communicate information about the End-User
Discovery – (Optional) Defines how Clients dynamically discover information about OpenID Providers
Dynamic Registration – (Optional) Defines how clients dynamically register with OpenID Providers
OAuth 2.0 Multiple Response Types – Defines several specific new OAuth 2.0 response types
OAuth 2.0 Form Post Response Mode – (Optional) Defines how to return OAuth 2.0 Authorization Response parameters (including OpenID Connect Authentication Response parameters) using HTML form values that are auto-submitted by the User Agent using HTTP POST
Session Management – (Optional) Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality
Front-Channel Logout – (Optional) Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
Back-Channel Logout – (Optional) Defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out

And for Client Implementations

Basic Client Implementer’s Guide – Simple subset of the Core functionality for a web-based Relying Party using the OAuth code flow
Implicit Client Implementer’s Guide – Simple subset of the Core functionality for a web-based Relying Party using the OAuth implicit flow

OpenID Connect core specification is about End-User authentication and basically it describes about two main flaws namely

1. Authentication using the Authorization Code Flow
2. Authentication using the Implicit Flow

respective client implementations are Basic Client implementation and Implicit Client authentication.

Most suitable mechanism for JavaScript applications is Implicit flaw because JavaScript or browser based application cannot securely store authorization code and client secret.

Here I explain Authentication for Single Page JavaScript application with WSO2 Identity Server.

Step-01 Register Service provider in Identity Server

Provide accessible URL. Here I am using "http://localhost:8000"

Now you can obtain Client Key and Client Secret

Step-01 Implement browser based JavaScript application

You can copy below code segment to index.html file and put into that into some folder like "web". Now you can start a simple python server with below command.
"python -m SimpleHTTPServer 8000"

<html>
<head>

<script>

function gup1( name, url ) {

    if (!url) url = location.href;

    name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");

    var regexS = "[\\?&]"+name+"=([^&#]*)";

    var regex = new RegExp( regexS );

    var results = regex.exec( url );

    return results == null ? null : results[1];

}



var outString="";

var idToken = gup1('id_token');

if (idToken!=null) outString = (JSON.parse(atob(idToken.split(/\./)[1])));

if (idToken!=null) console.log(outString);

if (idToken!=null) alert("Hello "+outString.sub);

</script>

</head>

<body>

<a href="http://localhost:9763/oauth2/authorize?response_type=id_token&scope=openid&nonce=1234&client_id=D4TlFF1muYo18BEABpF054ul2HAa&redirect_uri=http://localhost:8000">click</a>

</body>

</html>

Step-03 How it works.

Access the resource "http://localhost:8000"

Enter user name and password.

Now you can see Authenticated User.

securitywithsoa

Sunday, September 4, 2016

Authentication for Single Page JavaScript Application with WSO2 Identity Server

Blog Archive