I'm making use of Identity for my Web API. I am successfully able to retrieve an access token by providing the username and password, but I'm not entirely sure what to do with it afterwards. I am thinking about storing it in a cookie, but I'm not sure whether or not this is bad practice. If it is, what would be better alternatives to this solution.
I don't want to let a user login every time he visits the website, so because of that I'm looking for ways of storing the access token. I have been searching the web (and SO) for solutions to this problem, but did not find a suitable answer. I found the following question that's similar, but did not get an answer: Where to store OAUTH2 access token in mvc5 web app.
Thanks in advance for your suggestions!
Related
I have two sites, one of which is essentially embedded into the other, although they have to be loaded from different URLs. They both access the same backend API. I want the user to log in once and be able to access the API in the embedded site without having to log in again. Essentially, I guess this would be Web-SSO. To complicate things even further, the outer site is a legacy PHP site with a backend server, the inner is a single-page react app.
I'm looking for a way to pass the login from the outer site to the inner site, without actually passing a login token around e.g. as an URL parameter, which would probably not be safe.
Essentially what I'm looking for is something Site A can safely give to site B, that will tell the authrisation server "Site A is authorized, and Site A trusts Site B, so it's OK to give Site B a token too"
Does such a mechanism exist? Some people have suggested OAuth2 and OpenID to me, but in all the documentation I've read, I haven't found any description of this use case. To me, this looks like OAuth2 in reverse. All examples I have seen concern the use case "Site A wants to access Service X, so it needs to authenticate with the Auth server Y, to get a token that will let it access the service". A second site wasn't part of the picture in any of the examples I could find.
Is OAuth2 even the right technology for this, or do I need something else entirely? How does one implement this use case?
If I understand correctly, you just want/need SSO. Since if a user logged in in site A (or any *.domain.com or *.com that is registered as a "safe" application) it will also be logged into site B.
Essentially how this works is when the user is logged in there will be a cookie stored on this website and (not sure) also on the API login website. Then whenever the user tries to enter website B e.g. the application should check for a cookie on site B. If there isn't any cookie it will look for a cookie on the API login website. If there is it will automatically login (without credentials). This is basicly what you say.
Site A can safely give to site B, that will tell the authrisation
server "Site A is authorized, and Site A trusts Site B, so it's OK to
give Site B a token too"
This could be achieved by using a third party like Auth0. Im currently trying to implement this in Symfony. So far not much success but since I searched alot for other SSO providers I think this is the best shot. Also for your needs I belive it will work good enough.
Another option:
Create a API authentication server yourself. This way you have full control over it. But you need to manage it all yourself, also the security. There are probably packages that help you alot but still, you need to figure out alot by yourself.
My advice is to check out Auth0 by just creating a free account. See what it can offer and try some things out.
I am novice to how oauth2 with JWT works But must to learn it in short time :) After reading bit I draw a conclusion abstract of its work as this.
now I have two question in my mind.
(1) Is my way of understanding of how OAth2 work is fine ?
(2) As far as I know after step 6 (diagram) no further request to authorization server. Then,anyone(intruder) know the token witch given by auth server can communicate to the web API and obtain unauthorized access.how does is not possible.
(I know that token not alter by intruder since then web api new that but without altering it still intruder can communicate to web api)
I know I have miss something please kindly show me where I have missed ?
You have to take security measures to protect your token from being stolen. This is no different than preventing session-id from being stolen in session based authentication.
Anyone with access to a valid token is by definition an authenticated user, no matter how the token was retrieved.
Whether your web API communicates with the authentication system directly is not relevant.
I am trying to understand in what scenarios I should be using oauth. From reading the spec, I understand that you are essentially delegating identification to a 3rd party.
So if we take the example stackoverflow's login page you get
Oauth2 is being used for google and facebook, how do I determine what stackoverflow is using (when entering username and password directly)? Would that also be oauth 2? If it is using oauth, how would I go about understanding which flow they use?
Your question is a little unclear but what I think you're asking is if SO or some other site uses oAuth for all their authentication schemes. They could. If they using oAuth with user password authentication when you authenticate, the response you get back should have an Authorization Token and a Refresh Token in it that you would then use to authenticate on each successive request. Hope this helps. oAuth isn't a technology it's a protocol on how to do authentication in a better way.
See what is the request URL when you click to log in with gmail...
https://accounts.google.com/ServiceLogin?passive=1209600&continue=https://accounts.google.com/o/oauth2/auth?client_id%3D717762328687-p17pldm5fteklla3nplbss3ai9slta0a.apps.googleusercontent.com%26scope%3Dprofile%2Bemail%26redirect_uri%3Dhttps://stackauth.com/auth/oauth2/google%26state%3D%257B%2522sid%2522:1,%2522st%2522:%2522e35d652c26ae7fad9b61f6176cc93f2eb9bbb240c32231bc95f8270176d7a5d5%2522,%2522ses%2522:%252291fdf487240d4fa38576f780ad448f55%2522%257D%26response_type%3Dcode%26from_login%3D1%26as%3D-8520e47ae71bbb4&oauth=1&sarp=1&scc=1#identifier
Does that auth2 means oauth 2 ? I think so
UPD: As I understand OAuth mechanism is supported by 3-rd part. SO could use their own oauth for direct enter, or standard auttentication. It is up to SO.
To keep it short and easy:
If you want to add authentication to your application and you want to leave some security heavilifting to big companies like Facebook, Google and Stackoverflow it is generally a good idea if you do not know precisely how to handle such a delicate task and/or you are not using a specific Auth tool / framework.
On the other hand, from the user perspective, the application will be far more user friendly (just one click authorization instead of a painful registration).
If you want a much more detailed technical explanation I suggest you to read this other Stackoverflow post:
OAuth 2.0: Benefits and use cases — why?
I'm trying to implement an OAuth2 provider for my web service.
It seems easier to implement the Authentication Server together with the Resource Server. The specification doesn't say anything about the communication between them.
Does anybody see a reason not to do this?
I had a post yesterday regarding this issue. I hope we can mutual answer each other. First to directly answer your question, I think it depends very much on the load that your app has to handle. If you have to scale your app to many resource servers, keeping a separate auth server is the best because you can centrally manage user credentials and access_token in one place.
Here is my question. I believe if you have tried something similar to mine, you can give me some suggestions.
OAuth - Separating Auth Server and Resource server returns invalid token when accessing protected resource
UPDATE: I failed to mention earlier that we want solution that will be flexible with authenticating users from within our databases or by asking other servers to tell us if the user is authenticated. It is also worth mentioning that these other servers are not under our control so we can't enforce a specific user model.
I had a long and hard read on OAuth and OpenID but they are both not a suitable solution for our situation and will make the process harder to the user. This is something that has been solved a thousand times, yet I cannot find the solution.
What we are looking for is a framework that can be used in a REST services server to authenticate users (no third-party clients involved) with their username and password.
The solution must not pass the username and password except the first time on login and use tokens for further authentication. Even though OAuth does use tokens, it is designed to allow third-party clients access to the service-providers resources. That is not the case here, the services are for our own application only, the only thing needed is user authentication.
What do you guys think is the most appropriate solution?
Configuration:
-Spring server that provides RESTful services with our thinking going towards using Spring Security with some user management and token management framework.
-iOS Device that will be making HTTPS calls to the server.
What we ultimately want is to have the device send a login request and receive a token if the login was successful, later on make requests using that token. Just like Facebook, excluding third-party involvement.
Is there something that is ready to be configured in our server? Or should we consider building our own token management, comparison and generation software?
Is using Spring-Security with an iOS application without involving storing cookies or redirecting to pages possible?
OpenStack offers as part of it's many projects related to open source cloud... the project Keystone. Which does this pretty much exactly what you want.
You might want to check it out here:
http://docs.openstack.org/developer/keystone/