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?

  • "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 May 25 '16 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. – Dan Revell May 25 '16 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 May 25 '16 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. – Dan Revell May 26 '16 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 May 26 '16 at 11:09

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.