4

We're implementing a web application (US) that needs to exchange sensitive information with a third-party web application (THEM). The way we'd like it to work is that an end user clicks a hyperlink, navigates to the third-party web application and magically the sensitive information is available to the third-party web application.

As you'd expect, we'd rather not send that sensitive information along with the url the user clicked. We do not control the third-party web application, but we can impose how they integrate with our web application. We'd like to keep this as simple as possible from a technology perspective (low bar to entry so to speak). Obviously we have full control over our own web application.

We were thinking along the lines of having some sort of one-time usable, randomly generated, restricted in time, access token.

  1. We assume the end-user has been identified/authenticated.
  2. The end-user clicks a link which obtains an access token from our own web application. Since all sensitive information is available server side, there's no need to share it with the end-user's browser. We store the access token and its expiry date and time along with the sensitive information. The sensitive information cannot be derived from the access token itself. Our web application redirects the end-user's browser to the third-party web application with the access token in the redirection url.
  3. The third-party web application receives the incoming request and uses the access token to obtain the sensitive information by issuing a server side request for the information back to our web application. Our web-application returns the sensitive information and now the third-party web application can use said information. Obviously we'll handle access token removal, expiration, etc.

Apart from someone being able to obtain the access token in transit and having to secure the access token storage as well as the server-side communication between our application and the third-party application, do you see any other security holes? Instead of rolling our own is there any widely adopted standard we could use instead?

Improve this question

1 Answer 1

Reset to default
6

This is not terribly different than what OAuth is designed to do, if we were to tweak the workflow.

If you were to implement this using OAuth, your application would include an OAuth provider, and the third party would sign up to be an OAuth client.

The user, who is the resource owner, when redirected to the third-party site would simply authorize that site to access their resource (the secret) that your site is keeping safe for them.

The model looks like this:

enter image description here

Improve this answer
2
  • We already authenticated the end-user in our web application at an earlier point in time. Could (4.) be implemented in a way that doesn't require re-authentication? Also, having the end-user authorize access to the secret upon each request (link click) is not desirable. Maybe I wasn't as explicit as I could have been about this, but there's a high degree of trust between the web applications. Only a few are configured this way.
    – Yves Reynhout
    Jun 7, 2013 at 8:05
  • 1
    @YvesReynhout Yes, absolutely, at least from the perspective of your site. Once they get to the third-party site, if they're not already authenticated there, they'll need to authenticate in order to verify that they they own and authorize access to the resource. Once they've authorized access, the third party app can store the token and as long as it's valid, reacquire the resource on behalf of the user without the user having to authenticate again.
    – Xander
    Jun 7, 2013 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .