What are the security concerns with setting up this authentication handshake

Question

We have a custom online service that is private. My company can access it via SSO but there is no other login mechanism.

We have a business partner that has its own online portal, which its own clients get access to with a username and password. The partner would like to give its clients access to our online service. We want ensure that only valid clients of our partner can access our service. While they are on our service, the partner's clients will be able to save information and then retrieve it later.

We want to set up a very lightweight method to authenticate these clients onto our online service. We do not want them to create usernames or passwords or to need to login manually.

To achieve this, we propose doing the following, assuming there are no security concerns:

1. When a partner user is on the partner's portal, the user can click on a link to open up our service in a new browser tab. The link will include url parameters dynamically added:

   1. a unique identifier for the client user (perhaps an email address but it could instead be a userid). This could be encrypted.
   2. A session ID for their logged in session to the partner's portal. (This does not need to be the full sessionID. it can be encrypted, salted, etc. as long as the next part works). The sessionID will change every time the user logs in to the partner's portal. Assume the sessionid that is included is sufficiently complex/obfuscated to be impossible to guess.

2. When our online service receives the request, it will make a backend, secured REST call to the partner's portal (to a known URL), passing in the 2 URL parameters above userid and sessionID.

This is all done by making an https request to our service.

The partner's portal will respond to our request to indicate whether the information we provided is valid or not. If valid, we will give the user access to our service.

In our service, we would associate any data entered by the user with their user id and only show the user saved content that is associated with their userid.

The only potential risks I see are:

1. Someone who is not a client of the partner attempts to access our service using fake account information. This isn't really a security issue per se, because if that is successful the person would not have access to anyone else's data, but they would get "free" access to our service. However, I don't see how this is possible.

2. A non-client attempts to access our service using a real account. It's not clear how that would work. They would need a valid session id (and also know the userid of a valid and matching client). The session Id essentially acts as a password that changes on each login. I don't see any way that a third party could intercept the call from the partner portal to our service. It's just a GET call (or perhaps a POST) over HTTPS.

Am I missing any risks here? Does the above approach seem secure?

Answer 1

Why not use SAML? Your question seems like a description of the SAML use case.

I don't know your country (e.g. if GDPR applies), data types, connection types, contractual obligations, amount of data, encryption, hashing, firewall rules, application layers, security zones, and many other risk factors.

Overall, I would say that this is inadvisable, and unapprovable.

"However, I don't see how this is possible." -- Until you have a red team (EHT, white-hat, etc.) work on it for a while, never underestimate what is possible.