7

I need to create a container app which contains several apps (imagine something like iCloud): once I've been logged in, I can see all the apps by means of icons, click on them and use them (a new tab/page is open and no login is required).

The container app, as well as the other apps, will have a dedicated folder on the server and will be designed to be front-end apps with their own back end. Each back end is dedicated to the single app, but all the back ends can access server APIs and/or the DB without any problem (they will reside on the same server, at most on different virtual servers with different ports).

I would like to let the user log-in just once (container app) and then let her/him to use the app without re-logging in again and again. To do that, I was thinking about a shared token that each front-end app will send to their relative back ends. The back ends will check the token. I don't want to reinvent the wheel so I was wondering if oauth could be useful some way to accomplish my goal.

Brian Tompsett - 汤莱恩
  • 355
  • 2
  • 12
Bertuz
  • 417
  • 4
  • 10
  • 1
    To clarify, are these third-party applications you're writing a container for, or are you writing all of the apps the container cares about? – Ixrec Mar 18 '16 at 16:14
  • 1
    All the apps will be part of the container: think about the first case then – Bertuz Mar 18 '16 at 16:18
  • 2
    @PhilipCrowPersonal yes they can, because everything is written from scratch. I was actually documenting myself about the SSO (Single Sign On) and what I wanted is exactly what StackExchange has actually implemented: a login-once-navigate-through-different-websites solution. OAuth is great for Authorization, but here is more about authentication (if I got it right). I was wondering if an open framework existed though. Here is what I found: http://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work/64274#64274?newreg=e6ed36264e044485900ae5615b4b5679 – Bertuz Mar 19 '16 at 21:51

1 Answers1

1

One option would be to host all the applications under a single domain and have the login app write a cookie which each of the other apps read. If you really need to host applications on different domains then this won't work for you (as you can't read a cookie from a different domain), however if you can then this approach will save you a lot of headaches.

Alternatively you can use OpenID Connect. OpenID Connect is an extension of OAuth2 that specifies how identity / user information should be represented. In this case it might work a little like this:

  • One of your apps is an "OpenID Provider" (OP), which handles logging in users as is an OpenID Connect
  • One or more other apps are "Relying Parties" (RP), which depend on the OpenID Provider to log users in
  • When a user visits an app and is not signed into that app, it redirects the user onto the OpenID Provider using one of the supported flows (e.g. Implicit). The provider then authenticates the user (e.g. via username / password), and stores a cookie to track that users session.
  • The OpenID provider then redirects the user back to the app, who validates the id_token supplied and also stores a cookie
  • If the user then visits another application and is not logged in then that application redirects the user onto the OpenID provider as before, however this time the cookie that the OpenID provider stored means the user doesn't need to authenticate again, and the user is redirected straight back to the app with another id_token

This way multiple applications can all know who the currently authenticated user is without requiring that the user log in multiple times.

This is all done using OAuth2 (OpenID Connect is an extension of OAuth2) - I recommend using OpenID Connect (as opposed to rolling your own solution built on OAuth2) as it defines a standard way of handling these sort of scenarios, as well has how to handle things like Session Management and logging out.

Justin
  • 1,728
  • 10
  • 16