Let's say I'm main.com and my service is used by website owners clienta.com clientb.com

I need to verify the identity of users of client websites. (authenticate them)

My plan is implementing a backend view that's reached on client server like clienta.com/gotomain that will authenticate users locally however they do (session auth, cookie auth, etc.) and redirect users to main.com?token=j2j90ajsd90j2&sender=clienta with a calculated token and I will authenticate the users by token.

Token format will be sign(userid, CLIENT_A_KEY) so signed version of userid. (I'm thinking of JWT)

what are the attack vectors to this authentication? Is there anything fundamentally insecure?

  • 1
    Nitpicking over terms in the question, authorization (verify what an authenticated user can do) is not the same as authentication (verify claimed identity). But I understand you are asking about auth. I am not an expert in this field, experience wise, but there are existing attacks against JWT. Assuming you are interested in your implementation of it - for ideas see Incorrect Implementation in trustfoundry.net/jwt-hacking-101. It seems the token payload is not encrypted, it is only hashed. – HackneyB Feb 3 at 17:19

If I understand your question, you do not actually need to authenticate the users, you just need to make sure that the client web site considers them to be authenticated.

Your basic approach looks correct to me. The client website just needs to sign the user's token which includes whatever information you need (user id or whatever).

The main vulnerability would be somebody using an old identity or some kind of replay attack. So, you want to have some kind of time stamp or sequence number to make sure that authentications are new sign ins, not recycled ones.

Your Answer

