Is is safe to pass an API key in a HMAC hash?

Question

I have 2 websites: a.com and b.com
To avoid using SAML for Single-Sign-On and making things complicated, I've taken this approach:

a.com is the identity provider. All users will be asked to sign in on a.com
b.com will receive information from a.com on the session and sign them in on b.com. A part of this is b.com passing a random 128 character long "token" in the URL parameters to a.com like so:

a.com/login?token=TOKEN_HERE&point=b.com

If the user is not signed in, they are asked on a.com to provide their credientals. Once they are signed in or if they already were signed in, a.com then sends the token back to b.com with an HMAC SHA3-256 signature attached containing the API key:

b.com/login?
token=TOKEN_HERE
&uuid=6d43cb60-e5c2-11ec-8fea-0242ac120002
&sig=HMAC_SHA3-256_HASH

The sig variable is sent from a.com and contains several variables including the API key (secret) that only a.com and b.com know. The signature has the following:

• The random token 1st sent from b.com (&token=)
• The UUID of the user that's being signed in (&uuid=)
• The current time (not sent in URL params, verified server side only)
• The users IP address (also not sent in params; server side)
• The browsers user agent (not sent in params)
• Finally as the HMAC key, the API key that only a.com and b.com is used.
  
  If for some reason the API key that a.com & b.com use was exposed, anyone would be able to generate the sig variable hash and would be able to spoof who they are to b.com as they could easily find the token in the params, set the UUID to whatever they want, and the signature would match.
  
  My question is: Is it safe to pass the signature in the URL parameters and does this make it possible for someone to figure out the API key? If this approach is insecure, what would you recommend?

Answer 1

Is it safe to pass the signature in the URL parameters and does this make it possible for someone to figure out the API key?

If you use TLS, nobody will be able to see the URL parameters.

If for some reason the API key that a.com & b.com use was exposed, anyone would be able...

Sure. Users are responsible for keeping their API keys secret.

If this approach is insecure...

1. In your scheme, it is sufficient for user to login only once, then store token, uuid and sig. From now on user can always call b.com directly and add these request parameters. b.com will not know user was just authenticated by a.com or not.

2. Furthermore, users can share these parameters with other users. For users who share there is no need to disclose their authentication details, thus there is no privacy risk. And if your service does not generate additional costs to the users, then users will have no risk to share their token, uuid and sig with the others.

3. It is not clear, what party is responsible for authorization. If a.com is responsible, then there is no need to send API key from a.com to b.com. If b.com is responsible for authorization, then there is no need to send API key to a.com.

4. It is not clear what is the purpose of separation of functionality between a.com and b.com. For instance, if you had multiple services and wanted to have a single-sign-on, such scheme would be understandable. Or if you had an established authentication service that you wanted to reuse (e.g. 2FA, user registration, password resetting, etc.) and thus to reduce development efforts, such separation would also be understandable. But you have not provided any details why you split it in such way. That's why it is hard to say what could be good alternatives.