Update 5/12/2016: Building single sign-on for user management? Learn how to integrate OAuth with our OZorkAuth game!
Since the beginning of time, developers have been writing code to store and handle user accounts.
Then Stormpath came out and made that process a lot simpler. Instead of writing all that code yourself, you just make a few API calls to our service, and we take care of the heavy lifting: storing user info, handling authentication and authorization, ensuring data security, etc.
This brings us to the present.
We recently released our new ID Site product, a Single Sign-On (SSO) feature that makes it easy to completely remove user authentication logic from your web application. Now, you can handle it on a completely separate subdomain.
This authentication subdomain is hosted by us, so all you need to do is point your DNS records at us, add a few lines of code to your webapp, and BAM, you’ve got authentication ready to go!
ID Site offers a basic Single Sign-On experience, allowing your users to access multiple applications seamlessly, with one set of credentials — all within the same session.
This post will take you through what it is and how it works.
ID Site: Single Sign-On with Stormpath
ID Site is a hosted web app (built in Angular.js) that provides pre-built screens for login, registration, password reset — all the common end user functions of your application. It is fully hosted by Stormpath, which makes it really easy for your application to access these features, as well as add SSO across your apps, with very little code.
When you sign up for a Stormpath account, we’ll give you a configurable authentication subdomain that is ready to use – just add some basic information into our console:
the domains of apps authorized to use your ID Site, and callback URLs your ID Site is allowed to communicate with — AND JUST LIKE THAT — you are on your way!
How It Works
ID Site is easy — really easy — to integrate with your application. The functionality is already built into our client libraries.
At a high level, its very simple: when you want to authenticate a user, you redirect them (using our libraries) to your new authentication subdomain (like login.mysite.com, for instance), we’ll handle the authentication and authorization checks or any workflows like password reset or account verification, then we’ll redirect the user back to your application transparently.
Here’s how it works:
This seems complex and full of moving parts, but it really isn’t. To get your user to the ID Site to authenticate, this is what the code actually looks like (here’s a Node.js example):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
// Creating a simple http server in Node. http.createServer(function (req, res) { // If the user requested to login, we redirect them to the ID using the // Stormpath SDK. if (req.url==='/login') { res.writeHead(302, { 'Cache-Control': 'no-store', 'Pragma': 'no-cache', 'Location': application.createIdSiteUrl({ callbackUri: "https://myapplication.com/loginCallback" }) }); res.end(); } |
This code lands the user on your ID Site, which is fully customizable to your brand and hosted on Stormpath infrastructure:
Once the user logs in, they will be redirected to the callbackUri that was specified in the request. From there, you can validate the information and get the account for the login with the following code:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
if (req.url.lastIndexOf('/loginCallback', 0) === 0) { application.handleIdSiteCallback(req.url, function(err, result) { if (err) { showErrorPage(req, res, err) } else { if (result.status === "AUTHENTICATED") { req.account = result.account; showDashboard(req, res); } } }); } |
There are two ways developers can handle the callback from the ID Site. One is to have a callbackUri specific to each action, like login and the /loginCallback in the code above. The other is to have a generic callback, like /idSiteCallback that handles the response for all actions taken on the ID Site. Stormpath exposes a status so you can know what action occurred on the ID site for any given callback.
Although ID Site is built in Angular, you can connect to it from any application. ID Site support has been added to our Node, Java, and Python libraries, and is available through the Stormpath REST API, so you can take advantage of it even if you aren’t using one of those languages.
Why ID Site?
Almost every feature at Stormpath comes out of developer requests, and ID Site solves issues and use cases we hear about frequently:
- ID Site separates your user management and from your application code, which increases your application security and makes it easy to deploy new applications for the same user base.
-
Reads and applies the directory settings from Stormpath automatically, such as social login providers and password strength validation.
-
Supports Single Sign-On (SSO) natively with configurable session parameters.
-
You control your users’ experience: we’ve made the code available open source and customizable.
-
And of course, we’ve built in security features to cover common attack vectors without any additional code.
Stormpath Single Sign-On Demo
If you want to get a feel for how ID Site looks and feels to end users, I built a demo to show a basic Single Sign-On experience. This allows you to log into and share sessions across two different websites:
http://shielded-journey-8142.herokuapp.com
and
http://limitless-ravine-7654.herokuapp.com
Both of these web applications use ID Site and share a 5-minute session timeout.
To learn more, check out our Guide to Using ID Site In Your Application.
If you have any questions / comments, we would love to hear them! Let me know how to make ID Site more useful to you: ([email protected] or @omgitstom).