Search code examples
authenticationsecuritysingle-sign-on

Redirecting with Token Authentication Between Angular Apps: Pros and Cons?

I'm working on an Angular application (Site A) that implements a login system. After users log in, I want to redirect them to another Angular application (Site B) while passing along the authentication token generated by Site A. The goal is to allow Site B to recognize the user as logged in without requiring them to log in again.

My Approach:

Upon successful login on Site A, I generate a JWT token. I redirect the user to Site B with the token as a URL parameter (e.g., https://siteB.com?token=YOUR_TOKEN). On Site B, I extract the token from the URL and validate it.

Pros:

Seamless User Experience: Users can move between applications without additional logins. Simple Implementation: Sending the token via URL parameters is straightforward.

Cons: Security Risks: Sending tokens in the URL can expose them to potential interception through browser history or server logs. Token Expiry: Managing token validity and refreshing tokens may add complexity.

Questions:

What are the security implications of sending tokens via URL parameters, and how can I mitigate risks?

Is it better to validate the token on Site B by making an API call to Site A, or can it be done locally?

Are there alternative methods for implementing single sign-on (SSO) between separate Angular applications?

I’d appreciate any insights or suggestions regarding my approach!

Solution

  • I would aim to meet 2 requirements:

    • Avoid passing tokens in URLs which is a poor security practice, since tokens can leak to logs and be exploited
    • Each application should gets its own token for data access, with its own access to resources

    PREFERRED SOLUTION

    Ideally, use a standard protocol like OAuth 2.0 and OpenID Connect, where an authorization server provides single sign on capabilities to enable the above.

    ALTERNATIVE SOLUTION

    Another possible option, if you cannot achieve SSO in a standard way, is to design a solution around a one-time use token - called a nonce. These are safe to pass in URLs since they have a very short lifetime and can only be used once. A solution might work like this:

    SITE A

    • Calls a utility API and sends its ID token as a proof
    • The utility API validates the ID token, issues a nonce (like a UUID) and writes a database row with other details, like a 1 minute expiry and the user ID from the ID token
    • Site A then calls https://siteb.com/?nonce=FH23EU94HURT...

    SITE B

    • Receives a nonce and calls the utility API to introspect it
    • The utility API looks up the nonce in its database and checks it is not expired, then enables issuance of a token for Site B with the same user identity but perhaps different data permissions
    • The utility API then removes its database row

    This type of solution usually requires you to to customize the login flow for Site B, which may not be possible in some cases.