3

I find myself in a situation where I need to hand a user off from a mobile application into a web application. The mobile application is using WebAPI on the backend with OAUTH 2. The web application on the other hand is MVC using cookies.

I'm not able to change the web application in any meaningful way, but I have a requirement to not have the user to log into the website after they've already logged into the app.

So my thinking is add an entry point route to MVC, that doesn't require auth and takes as parameters the token used on the api, and the url the user desires. The controller would authenticate the token, issue the cookie and the redirect the user to where they want to go.

This would be an invisible hand-over controller. It makes a kind of sense and it should be easy to do, but I feel uncomfortable logging the user into the site without going through the typical route.

Are there potential vulnerabilities in this approach?

Improve this question
7
  • "So my thinking is add an entry point route to MVC, that doesn't require auth and takes as parameters the token used on the api" ..... so "your thinking" is you want to create a backdoor. Good luck with keeping that secure !
    – Little Code
    Commented May 25, 2016 at 10:24
  • @LittleCode Thats for the feedback. I expressed myself that I was uncomfortable with the approach but it might well be the right one. It's not exactly a backdoor, more a non-standard second front door. The reason I put this post here was to create a discussion on pitfalls of the approach and hopefully hear someone suggest a possible alternative.
    – Daniel Revell
    Commented May 25, 2016 at 10:46
  • 1
    @LittleCode How is that a backdoor? Seems like a perfectly valid scenario. The token has to be passed in ANY case, so it's just passed in the URL this time (not in a body of a POST e.g.). So there are some problems with it being sent to URL, but if the token is short lived, should be OK.
    – Ilya Chernomordik
    Commented May 25, 2016 at 20:25
  • @IlyaChernomordik thats a great point, but now you mention it, I don't see why the token can't be in the body. i control both the client and server so i can just say the client has to post to the entry point. this way the token is a little more secure as compared to the url.
    – Daniel Revell
    Commented May 26, 2016 at 8:44
  • @DanRevell, I am not sure if it's possible to achieve, since it's only a url opened from an app to a browser. So perhaps one ordinary http get with URL is all you can do.
    – Ilya Chernomordik
    Commented May 26, 2016 at 11:09

1 Answer 1

Reset to default
1

I had a similar problem to solve, but from a URL in SMS (simple logon, without username/password). So I generate one time code for it, but you can as well use the existing token (you need to know the keys of course to decrypt or validate it).

You can find details of my approach here with an answer on how secure that approach is. So you can always generate this one time tokens for logon that are valid for say 30 seconds, so it will be very hard to abuse in this short time as far as I can see (though of course you'll need more entropy in the token than I needed for SMS).

Otherwise if you can reuse the same token in the web application, then you don't even need to validate it in this additional request: just issue the cookie with what you got as a parameter, redirect and let MVC handle the rest.

Improve this answer

You must log in to answer this question.

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