0

In my case, company B (domain B) hosts a portal, which has link to my web app (domain A). If user clicks on hyperlink on the portal to my domain, he/she should be automatically logged into my app.

Existing poilicies that i cannot change:

  1. User also has the ability to log into my domain directly, without going through the portal by supplying user id/password.
  2. Also, existing company policy for user provisioning is that even if user log through portal of company B, they first need to have a user account with my company. Hence, the user will have account with portal company and my company.

Given these constraints, my plan for is following to provide automatic login from the portal.

When the user logs in to the portal, the portal company will generate a temporary token (UUID) and attach it as a query parameter to the hyperlink to my web app. When user clicks on my web app's hyperlink, my web app will receive a GET/POST request on the server side for a protected resource. At the server side, my web app will over https (probably two way SSL) invoke a URL on the portal's side, passing the temporary token. The portal side responds with a user id. My web app will map the user id with user's credentials and create a session for the user and allow access to the protected resource.

When the user logs out of the portal application, the portal server will make an Https request to my web app at a prespecified URL to log the user out. Since it would be two way SSL, logout url is protected.

My questions are following:

  1. Is there a standards based approach to achieving the above scenario. In near future, my company is planning to support OAuth 2.0 and i want to ensure that the above scenario will not violate any OAuth standard. As per my understanding, OAuth 2.0 leaves the validation of the access-token to the implementations. I am hoping that the temporary token described above is sort of access-token.

  2. Once the user closes the portal browser, is it possible for browser to destroy the cookie. In this case, if user opens another browser later on, he/she should authenticate again.

Jimm
  • 8,165
  • 16
  • 69
  • 118

1 Answers1

0

Is there a standards based approach to achieving the above scenario. In near future, my company is planning to support OAuth 2.0 and i want to ensure that the above scenario will not violate any OAuth standard.

You kind of like answered your question already. That "standard-based approach" is OAuth which a Standards Track already documented by IETF in RFC 6749 and has been adopted by many software entities. If you don't implement OAuth then you are not violating the standardisation rules, you will be violating it if you claim to have implemented OAuth authorization in your system which clearly you haven't.

As per my understanding, OAuth 2.0 leaves the validation of the access-token to the implementations.

Well, OAuth is a bit more complex than just generating an access token, there's an authorization grant request involved before you can request an access token. You could also expose a token refresh endpoint if the life span of the access token needs to be extended by the client. So, there's more than just access token requests involved in OAuth authorization process

I am hoping that the temporary token described above is sort of access-token

What's an access token? It is up to you how you implement an access token, the implementation details belong to you and nobody else. The only thing that you need to guarantee is that the access token represents the authorization issued to client and its scope, in other words, given an access token your system should be able to identify a client and the scope of this client...what the client is allowed to do, what resources the client is allowed to request. Be aware that OAuth defines clients which doesn't directly translate to users, it could well be a user, another system, component or app.

Once the user closes the portal browser, is it possible for browser to destroy the cookie. In this case, if user opens another browser later on, he/she should authenticate again

Absolutely, yes. This is not related to OAuth at all, it's up to the client what they do with the access token and how they store it. If your system issues a non-persistent cookie, then as soon as the user closes the browser then the browser session is destroyed and also the cookie. All modern web development technologies offer cookie management implementations such as JSP, ASP.NET, PHP, etc. So I would suggest to store the access token in a non-persistent cookie and have your authorization server inspect requests to all protected resources by checking for the authentication ticket/cookie (where the access token is) and validate the access token, if the access token (or cookie) is not present then reject the request since it is an anonymous request to a protected resource.

Hope it makes sense

Community
  • 1
  • 1
Leo
  • 14,625
  • 2
  • 37
  • 55
  • Leo in the implicit authorization grant, the conversation is between client and authorization server. In this case, both client and authorization server are the portal company, aka out side my web app. Once the authorization server issues an access-token, that is where my app comes into the picture. My web app receives an access-token and as you said access token format is upto implementation. On receipt of access token, my web app verifies the token with authorization server, which again is outside the oauth spec. So where am i violating the oauth spec? – Jimm Feb 05 '14 at 02:08
  • Sorry, I'm still unable to see where your web app is requesting an authorization grant from the portal. In OAuth, one party cannot play both roles (client and server) at the same time and there's no such thing as implicit authorization grant since the authorization grant is explicitly requested by the client and issued by the authorization server. Don't get me wrong, your solution might work for you and could even be easy scale to OAuth but it is not what the OAuth protocol states. The communication between client-server is explicit and even the uri format is explicit – Leo Feb 05 '14 at 02:34
  • and yes, you're right about the refresh token. I guessed I phrased it incorrectly – Leo Feb 05 '14 at 02:34
  • My web app does not make any request to portal, so i am confused as to why should my web app require any authorization grant, infact, its the opposite case. The portal is requesting access to my web app. So the scenario is that portal have their own authorization server and my web app has its own authorization server, which in future will be OAuth2.0 based. So, i need to bridge the two authorization servers so that user does not have to log into my web app second time, keeping in mind that when my web app migrates to oauth 2.0, the portal to web app integration does not change – Jimm Feb 05 '14 at 02:53
  • @Jimm I have never implied that your web app should request anything from your portal. I was merely replying to your questions :) You stated you want to make sure your solution doesnt violate the OAuth and further asked how to destroy the cookie. Well, I was just explaining why it is violating OAuth and how the cookies are handled by browsers. As a side-note, if (and only if) you want to implement OAuth there's a few things to take into account and the main thing is determining the role of each component in your system... – Leo Feb 05 '14 at 03:21
  • It doesn't matter which one is the client and which one is the server. Just make sure you make an informed decision. If your web app requests resources from your portal, then your web app is most likely to be the client, however, if your portal requests resources from your web app then the portal could be the client. If none of these request resources from each other then why not implement a third component? An authorization server (AV)? Then both the portal and the web app will authenticate with (AV) – Leo Feb 05 '14 at 03:27