HTTPjs – a new API debugging, prototyping and test tool

Today, we released a new API debugging, prototyping and test tool that is available at:

When you arrive at the site, you’ll immediately be delegated a separate sub domain, such as This subdomain is now ready to receive any kind of HTTP requests. At the site, you get a javascript editor window, where you can prototype the server side of the API server.

All requests sent to your new domain, will be processed in your browser with your custom javascript implementation. The web site will display the full HTTP log for you to inspect.

This tool is very useful for rapid development, and testing of API clients. In example, you may select a template OAuth Server implementation to start from, then attempt to return variations, invalid responses and similar to inspect how your client behaves.

The tool was made possible with Node.js, Websockets with, Expressjs, requirejs, Grunt,, nconf, select2, ace, bootstrap, momentjs, highlightjs.

Posted in Javascript, OAuth, UWAP | Tagged , , , , , , , , , , , , | Comments Off on HTTPjs – a new API debugging, prototyping and test tool

API Authorization as a Service

Authentication and authorization with APIs are slightly more complex than with traditional access to web sites. The client is typically more intelligent, it being a javascript web application or a mobile native app; and communicates with a backend using an API. APIs typically also are exposed to third party app developers that may obtain access by both authenticating the third party client and the end user using it. This three-tier trust model is often referred to as “delegated authorization”.

Read more

Results from most of my current work will be primarily published on the blog.

Posted in UWAP | Comments Off on API Authorization as a Service

UNINETT WebApp Park Architecture

Here is a short description of the UNINETT WebApp Park Architecture.

Posted in Groups, OAuth, UWAP | Comments Off on UNINETT WebApp Park Architecture

Announcing UNINETT WebApp Park

I’ve spent a few months working on a prototype of UNINETT WebApp Park. The UNINETT WebApp Park is a simple, scalable, efficient and secure ecosystem for rapid development of modern web applications for higher education. I’ve created a 20 minutes walk-through video of the prototype. This is just the beginning, and I’ve got a bunch of ideas of further work on the platform. If you take the time to watch it, I really appreciate it, thanks!

I really appreciate feedback. Thanks.

Posted in UWAP | Comments Off on Announcing UNINETT WebApp Park

Serbian translation of SimpleSAMLphp

SimpleSAMLphp is now translated to Serbian. Thanks a lot to the Serbian team!

The translation is committed to trunk, and will be part of the upcoming 1.10 release.

Posted in SimpleSAMLphp | Comments Off on Serbian translation of SimpleSAMLphp

Announcing New Sparkling SAML 2.0 Debugger

I’ve done a rewrite of the old webbased SAML 2.0 debugger, which will help you to decode the various SAML bindings for easier debugging SAML messages.

I hope you like it.

This tool is part of the Federation Lab suite of test, validation and debugging tools for Identity protocols, such as SAML and OpenID Connect. Please contact me about any problems or bugs with the tool.

You may also be interested in the SAML-tracer Firefox Plugin.

Posted in Federation Lab, GN3 Identity Federations | Comments Off on Announcing New Sparkling SAML 2.0 Debugger

OpenID Connect Federations

I’ve done another take on OpenID Connect Federations based upon the current implementors draft of OpenID Connect 1.0.

Here is the idea:

Posted in GN3 Identity Federations, IdP Discovery, OpenID Connect | 1 Comment

Announcing online JWT Debugger tool

JSON Web Token (JWT) is a really nice IETF spec for encoding, signing and encrypting a set of claims using JSON. JWT is a standalone spec that is already used several places, but is also an essential part of the emerging OpenID Connect.

Today I’m anonuncing a online JWT debugger tool that allows you to decode and encode JWTs. This tool is part of the Federation Lab test and debugging suite for identity protocols. The Federation Lab also contains testing tools for OpenID Connect and SAML.

This is considered a beta version, and I’ve not quality controlled the output. The tool is also currently limited to the HS256 algoritm, but if people like the tool we may add more algoritms. Please give feedback if the tool does not work as expected or you have feature requests.

Posted in Federation Lab, GN3 Identity Federations, IETF, Javascript, OpenID Connect | Comments Off on Announcing online JWT Debugger tool

This document is also the of the JSO library.

Using JSO with Phonegap and ChildBrowser

Using JSO to perform OAuth 2.0 authorization in WebApps running on mobile devices in hybrid environment is an important deployment scenario for JSO.

Here is a detailed instruction on setting up JSO with Phonegap for iOS and configure OAuth 2.0 with Google. You may use it with Facebook or other OAuth providers as well.


Setup App

To create a new App

./create  /Users/andreas/Sites/cordovatest no.erlang.test "CordovaJSOTest"

Install ChildBrowser

The original ChildBrowser plugin is available here.

However, it is not compatible with Cordova 2.0. Instead, you may use this fork of ChildBrowser which should be working with Cordova 2.0:

What you need to do is to copy these files:

in to your WebApp project area, by using drag and drop into the Plugins folder in XCode.

Now you need to edit the file found in Resources/Cordova.plist found in your WebApp project area.

In this file you need to add one array entry with ‘*’ into ExternalHosts, and two entries into Plugins:

  • ChildBrowser -> ChildBrowser.js
  • ChildBrowserCommand -> ChildBrowserCommand

as seen on the screenshot.

Setting up your WebApp with ChildBrowser

I’d suggest to test and verify that you get ChildBrowser working before moving on to the OAuth stuff.

In your index.html file try this, and verify using the Simulator.

<script type="text/javascript" charset="utf-8" src="cordova-2.0.0.js"></script>
<script type="text/javascript" charset="utf-8" src="ChildBrowser.js"></script>
<script type="text/javascript">

    var deviceready = function() {
        if(window.plugins.childBrowser == null) {

    document.addEventListener('deviceready', this.deviceready, false);


Setting up JSO

Download the latest version of JSO:

The documentation on JSO is available there as well.

The callback URL needs to point somewhere, and one approach would be to put a callback HTML page somewhere, it does not really matter where, although a host you trust. And put a pretty blank page there:

<!doctype html>
        <title>OAuth Callback endpoint</title>
        <meta charset="utf-8" />
        Processing OAuth response...

Now, setup your application index page. Here is a working example:

<script type="text/javascript" charset="utf-8" src="cordova-2.0.0.js"></script>
<script type="text/javascript" charset="utf-8" src="ChildBrowser.js"></script>
<script type="text/javascript" charset="utf-8" src="js/jquery.js"></script>
<script type="text/javascript" charset="utf-8" src="jso/jso.js"></script>
<script type="text/javascript">

    var deviceready = function() {

         * Setup and install the ChildBrowser plugin to Phongap/Cordova.
        if(window.plugins.childBrowser == null) {

        // Use ChildBrowser instead of redirecting the main page.

         * Register a handler on the childbrowser that detects redirects and
         * lets JSO to detect incomming OAuth responses and deal with the content.
        window.plugins.childBrowser.onLocationChange = function(url){
            url = decodeURIComponent(url);
            console.log("Checking location: " + url);
            jso_checkfortoken('facebook', url, function() {
                console.log("Closing child browser, because a valid response was detected.");

         * Configure the OAuth providers to use.
            "facebook": {
                client_id: "myclientid",
                redirect_uri: "",
                authorization: "",
                presenttoken: "qs"

        // For debugging purposes you can wipe existing cached tokens...
        // jso_wipe();

        // Perform the protected OAuth calls.
            url: "",
            jso_provider: "facebook",
            jso_scopes: ["read_stream"],
            jso_allowia: true,
            dataType: 'json',
            success: function(data) {
                console.log("Response (facebook):");


    document.addEventListener('deviceready', this.deviceready, false);

Posted on by Andreas Solberg | Comments Off on OAuth 2.0 with Phonegap + ChildBrowser using the JSO library

Technical details on how DiscoJuice works

There are several roles of the play of DiscoJuice, each falls into separate same-origin policies. (not all the domain names are not real, but used as an example)

  • The web service provider, that needs to know which provider to login the user;
  • The DiscoJuice static content, including the script, some UI elements, such as images and css; provided from
  • DiscoJuice JSON Metadata feeds, a compact optimized metadata document for federations using JSON;
  • An IP to geo JSONP lookup service; running on
  • One or more existing discovery services;
  • A new central passive discovery service;

Installing DiscoJuice

The web service, includes in the web template of the service at a script element referring to the static DiscoJuice javascript running at

Also the web service includes a response.html page at This is used to receive responses from IdP Discovery Services.

DiscoJuice Operations

When a user clicks a login button or otherwise invokes DiscoJuice. The browser loads the script from, but runs in the context of The script draws the core UI of DiscoJuice on the screen, embedded in the web page running on The CSS and images are loaded from

Now, DiscoJuice loads one or more metadata feeds using JSONP from also caches provider logos adjusted to an appropriate size (approx 40x60px). On an engine runs to generate JSON metadata from SAML 2.0 Metadata, and postprocessing logos etc.

In parallell, the uses the JSONP interface of to get the estimated geo-location of the current user, based upon lookup of IP address. This is used to preselect the country in the UI, and as a fallback geo-location of the user used to sort the entities based upon distance.

Then DiscoJuice if configured make passive IdP Discovery Requests to a set of configured Discovery Services. These requests is compatible with all existing WAYFs or Discovery Services, by using the IdP Discovery Protocol. The user is not redirected, instead the scripts load a hidden iframe within the body of the web service. The iframe’s src points to the IdP Discovery endpoint at the discovery service endpoint of a remote discovery service. The return parameter to these iframe URLs are pointing back to the response.html running on These requests are made to check if the user has preselected any provider in any of the remote discovery services. Obviously these requests are made passive and does not always return any result, but never involves UI. The iframe content is redirected back to the response.html page with the selected provider as a query string parameter. The response.html page has a inline script that parses the response from the IdP Discovery protocol, and sends this to the parent frame (this run in the same-origin), DiscoJuice main script receives this and adjust the list of providers.

When the user has selected a provider, DiscoJuice can store use a simple addition to the IdP Discovery Protocol to be able to set the value of the selected provider on a remote domain; such as DiscoJuice includes a hidden iframe similar to the approach above, but with a providerID set in the request. DiscoJuice has two implementation of an extended version of the Discovery Protocol, a server-side and a client-side implementation. The servier-side implementation typically uses cookies to store the selected provided in the context of A client side implementation can use cookies or localStorage. uses access control to only leak preferred providers to clients registered in metadata, using the already established elements for that in SAML 2.0 metadata.

As a result the preferred provider is always shown on top of the list, even when the user moves between service providers running in completely separate domains. DiscoJuice achieve this even though the DiscoJuice script runs in the local context of the service provider.

Posted in IdP Discovery | Comments Off on Technical details on how DiscoJuice works