OAuth2, SAML, OpenID connect – Which one to use for my scenario?

I work for a company where we give customer (hundreds/thousands of users) access to 2 sites. One owned by a 3rd party SaaS and one owned by us. Customers spend alot of time registering for both sites and we also spend alot of time removing accounts when customers no longer need access.

I would like users to register for Site A. After successful authentication; a user can click on a link within the site to access Site B but without the user entering credentials. I want Site A identity to be used to access site B and its resources. I do not need site B resources to be presented on Site A site, but simply allow users to access site B if already authenticated to site A.

Users may have different roles on site B.

What is my best option? Oauth2 sounds like a good option. But will it satisfy my requirement above?

Who will manage the authorisation server? I presume Site B?

Thank you.

Recommendation for managing OAuth2 user consent

I went through RFC6749 to learn about OAuth2 but I found that the RFC didn’t talk much about how to store/manage the user consent at the authorization server. A common question when handling the user consent is that how long it should live: to have a defined TTL, per login session, or permanent until revoked explicitly.

I couldn’t find an answer for this when looking at several OAuth2 implementations such as Auth0, Google Identity Platform or Okta. Looks like each platform handles user consent in it own ways and there is no standard recommendation for it.

Does anyone has experience on this, or has any source of recommendation for managing OAuth2 user consent to be shared?

Thank you.

Registration process by OAuth2

I have been analyzing security process in 3gpp specs and the registration process in the spec. explained with that flow. The flow represents the registration of a client to the server.From SPEC. spec 2

I am not a security specialist and i do not understand why we send Oauth2 token in step 1. Doesn’t the access token send after the registration? I know that the access token used for authorization if the client known. I know that is a weird topic and I tried to explain it briefly i hope you understand if you dont you can always ask me.

Should OAuth2 proprietary client authorization prompt a confirmation window?

Given a company named X.

X has an OAuth 2 API available for its proprietary clients and also for 3rd party clients.

When a user P enters the process of authorizing a client, it is prompted with a window (right after authentication) showing several information (such as the application name, the scopes required, etc…) and must either click “confirm” or “cancel” to continue the process.

While having the user being able to confirm/deny authorization requests from 3rd party clients makes senses, does it still make sense to show this confirmation window for X‘s proprietary clients?

  • Is there something in the standard that forces to have this confirmation for every authorization request?
  • Is there a best practice in regards of that, that everyone agrees to?

What is the correct way to implement the OAuth2 state parameter?

I’m trying to understand how to properly implement state in an OAuth2 client, to mitigate CSRF attacks. This answer explains the attack scenario pretty well, to summarize:

  1. The attacker starts the authorization code flow, and gets a code from the authorization server
  2. The attacker traps his redirect url (e.g. https://client.com/exchangecodefortoken?code=attacker_code), and tricks a victim into accessing that link
  3. The victim is logged in with the attacker account, and if he upload sensitive info to the client application, that info will be uploaded to the attacker’s account meaning the attacker will have access to it.

The RFC vaguely says that state should be derived from the user session, for example using a cookie:

The client MUST implement CSRF protection for its redirection URI. This is typically accomplished by requiring any request sent to the redirection URI endpoint to include a value that binds the request to the user-agent’s authenticated state (e.g., a hash of the session cookie used to authenticate the user-agent). The client SHOULD utilize the “state” request parameter to deliver this value to the authorization server when making an authorization request.

This question implements this by creating an id cookie and a random state for each session, and correlating those two in the client DB. The client then handles an authorization code callback (e.g https://client.com/exchangecodefortoken?code=abc&state=def) by verifying that:

params.state == DB_at(cookies[id]).state 

It seems to me that an attacker can still bypass this kind of protection, because he knows his own id cookie:

  1. The attacker starts the authorization code flow, and gets a code from the authorization server
  2. The attacker traps his redirect url (e.g. https://client.com/exchangecodefortoken?code=attacker_code&state=attacker_state). He then uses that URL to prepare a link that when clicked, also sets the id cookie to the attacker’s id cookie (not very familiar with cookies, but this answer implies you can do this)
  3. The victim accesses the malicious link, and is redirected to the client with the attacker’s state and id cookie
  4. The request passes aforementioned verification and the victim is logged in with the attacker’s account – the attack succeeded.

How should you securely implement the state parameter?

(I’ve also seen answers like this one that claim that the attack is the other way around: at the end the attacker gets access to the victim’s account – and not vice versa. I though the explanations given for this scenario are incorrect/incomplete, but please correct me if I’m wrong on this)

OAuth2 – Sending a hash of your client_secret when using the client credentials grant instead of the secret

I’m working on an API that I’d like to be accessible internally by other servers as well as devices that I consider both as confidential private clients. Devices are considered private clients because the client_secret is stored in an encrypted area that prevents from unauthorised readout and modification (even though nothing is never bullet proof)

For auth, I’d like to use OAuth2 with the client_credentials grant that seems to be a very good fit for these use cases. However I’m wondering how flexible is the standard regarding sharing the client_secret.

Basically the RFC doesn’t say much about sending your client id / client secret, it just offers an example here: https://tools.ietf.org/html/rfc6749#section-4.4.2 which is very simple by using the following header Authorization Basic: base64(client_id:client_secret)

In my opinion, it could be slightly more secure by computing a hash:

  1. the client requests a random to the server by sending their client_id
  2. the server replies with a random code (valid for like 10 mins, just like an authorization code)
  3. the client computes a hash = sha256(client_id, client_secret, code) and asks for a token
  4. the server computes the same hash, compares the client hash with the computed hash and sends an access token if they match

It would add an extra layer of security in case https is somehow broken or if anyone is able to read the header somehow.

However it doesn’t seem very OAuth2 compliant and I don’t really like re-inventing a standard. Another option would be to create my own extention grant, I’m just wondering if it’s really worth it, like no one seems to have done this.

Also, if I want to share my API with a 3rd party app, not sure it’s a good thing to force them into using something non really standard.

Combining User Context in Machine-2-Machine OAuth2 Client Credential Flow

I have a REST API that is used by 2 separate application and is authenticating them by M2M OAuth2 Client Credential Flow.

enter image description here

One of the two application is an automation service without user context. The second one is a REST API where users authenticate with OAuth2 Implicit Flow.

Now I need to include the user context in my common REST API too, since some information should only be shared to certain users.

What is a secure strategy to implement that scenario with OAuth2? I thought I could just include the user (or a fixed string in case of the automation service) into the Access Token of the Client Credential Flow but that doesn’t seem possible.