21

So. I have domain A.com, of which the user authentication is done at domain B.com. Currently I have it set so that the login form is posted to B.com, which (if succesfull) sets the session cookie and fires redirect to A.com/loggedin. However, as the form is posted to the B.com and the cookie is set to that domain, when I do JSON request from A.com the session cookie isn't available an I have no idea if they logged in or not. The question then becomes, how to solve the issue?

I've been mulling over a solution wherein I would add a token to the redirect uri, which then could be used for one time authenticated session creation with A.com (the browser could use that token to auth the session with B.com, so that the cookie would be set to A.com and would be available on JSON requests. After that the token would be invalidated ofc).

However, I'm not sure how secure this solution would be? Or is there an other more secure solution?

crappish
  • 2,688
  • 3
  • 28
  • 42
  • how about sso solution. A.com need authentication, then redirect to sso server(S.com), S.com return to user a longin form, post to S.com. S.com received and generate a token,and redirect to A.com with the token, A.com get the Token, call S.com to fetch the logined userinfo. – Nile Nov 21 '13 at 09:15
  • and some also, openid solution – Nile Nov 21 '13 at 09:19

4 Answers4

10

Your current solution looks good to me and can be used in this scenario. But for your security concerns, instead of providing a plain token you may want encrypt it with some good encryption method and based on that you can configure your servers to encrypt and decrypt the authentication token before using it. The only thing is that you need to choose the best algorithm for your case.

Other than this solution you can give a think to session management tools. Session Migration, Session Replication and Session Sharing are the options that I can think of.

Here is Link for a solution provided by Oracle for session sharing, which I think can help in your case.

me_digvijay
  • 5,374
  • 9
  • 46
  • 83
  • I don't see how encrypting a token increases security? The server has to provide the token to the user before redirecting him/her. Even if the token is encrypted, it is still exposed to anybody "watching", e.g. in MitM-Attacks. The hacker still has access to the session information, since the server would decrypt the correct encrypted token... You'd need a highly complicated algorithm similar to SSH just to protect and verify the integrity of the token. That's just plain paranoid, if you ask me... However, +1 for the Session Sharing hint. – Kiruse Nov 21 '13 at 17:54
  • 1
    Like Derija said, the token encryption doesn't solve anything as it's still transmitted as plaintext. But +1 for the session sharing stuff. Thanks! – crappish Nov 21 '13 at 20:39
  • 1
    Encryption definitly will not work with web browsers, but with some other application (may be a swing app) where encryption is implemented at clients also, this will help. – me_digvijay Nov 22 '13 at 14:19
4

Yes there are more secure options.

For Single Sign On there is an open standard called OpenID/connect (built on top of oAuth2.0) For resource sharing, authorization and authentication there is oAuth.

Things to bear in mind.

  1. All of these solutions are little more than controlled security leaks - use carefully.
  2. All of these solutions leave you vulnverable to XSS, man in the middle and hijack / replay attacks.
  3. Because of points 1 and 2, careful implementation is critical.

Leverage the work already done by the community.

oAuth 1.0a (still widely accepted as the most secure pattern so far) - https://www.rfc-editor.org/rfc/rfc5849 oAuth 2 - http://oauth.net/2/ (using openID for authorisation built on top of oAuth2)

oAuth 2 is NOT a replacement for oAuth 1a - it is an entirely new (less secure) idea heavily dependant on SSL - oAuth1a is still the most secure - but still only as good as your implementation and understanding of potential weaknesses.

You are probably looking for openID connect ideas - but oAuth info is also useful...

SO - starting point of some differences

openID connect (layered on oAuth 2)

oAuth concepts

SO - worth a read

Community
  • 1
  • 1
LFN
  • 97
  • 1
  • 5
  • I'm not at all convinced about the accepted answer here. Encrypting the token isn't enough. Without signatures and identity verifications surely this is wide open to attacks? – LFN Nov 21 '13 at 20:47
  • 4
    OAuth 1.0 absolutely should _not_ be used anymore as it is obsoleted by OAuth 2.0 as explicitly stated in the RFC: https://tools.ietf.org/pdf/rfc6749.pdf – thisguyheisaguy Feb 27 '19 at 23:15
4

Security Assertion Markup Language (SAML, pronounced "sam-el"[1]) is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is a product of the OASIS Security Services Technical Committee. SAML dates from 2001; the most recent update of SAML is from 2005.

The single most important requirement that SAML addresses is web browser single sign-on (SSO). Single sign-on solutions are common at the intranet level (using cookies, for example) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies. (Another more recent approach to addressing the browser SSO problem is the OpenID protocol.) The SAML specification defines three roles: the principal (typically a user), the identity provider (IdP), and the service provider (SP). In the use case addressed by SAML, the principal requests a service from the service provider. The service provider requests and obtains an identity assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision – in other words it can decide whether to perform some service for the connected principal.

Before delivering the identity assertion to the SP, the IdP may request some information from the principal – such as a user name and password – in order to authenticate the principal. SAML specifies the assertions between the three parties: in particular, the messages that assert identity that are passed from the IdP to the SP. In SAML, one identity provider may provide SAML assertions to many service providers. Conversely, one SP may rely on and trust assertions from many independent IdPs. SAML does not specify the method of authentication at the identity provider; it may use a username and password, or other form of authentication, including multi-factor authentication. A directory service, which allows users to login with a user name and password, is a typical source of authentication tokens (e.g. passwords) at an identity provider. The popular common internet social networking services also provide identity services that in theory could be used to support SAML exchanges.

http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

Tashdid Khan
  • 53
  • 4
1

Using an authentication token should work fine, but consider these points:

  • Use a strong PRNG to generate the token, and generate a long token to prevent bruteforcing
  • Make sure a used token will instantly be invalidated to prevent replay-attacks

These both points are very critical in my opinion to prevent hijacking of the authentication token an reusing it. Also limit the time the token is valid (30 seconds should be fine) to prevent abusing of old/unused tokens.

thebod
  • 462
  • 2
  • 4
  • What about signing the token? Otherwise how would B.com know the token was issued by A.com? – Jatin Jan 23 '19 at 05:42