There exists OAuth extension to manage grants called Grant Management for OAuth 2.0.
It says we have to return grant_id at token endpoint and later we can use it in another authorization request.
But imagine a scenario:
The client redirect user to authorization server, receives grant_id
The user logs into another account at authorization server
The client redirects user with grant_id. Now, the user id associated with grant_id is another than id of user currently logged in authorization server.
It could be a big privacy issue if authorization server could have not checked if the user id of logged in user is another than the associated with grant_id.
But what authorization server have to do in this case? Shall return error? Force user to login into valid account? Or maybe ignore requested grant management params?
Specification doesn't say what to do in such a case and I'm really confused.
Related
I have implemented an OAuth2 register workflow (in Java) according to rfc6749
I'm using GitLab as OAuth2 Provider.
After the user granted access to my application for his account, I get an OAuth Token (along with refresh token and other stuff), I am able to make API requests on behalf of the user, so this is working fine.
This way I can get the users e-mail adress which I use to create an internal user.
My questions are:
Is it practice to issue a token that is generated by my application for the user (along with the OAuthToken) or should I just use the token that has been issued by the OAauth Provider? (My App also has local auth with bearer tokens). This token will be used for further API - CLIENT communication (stored in Angular2 local storage as bearer)
How to do login only? When a OAuth User accesses my web service, how do I know that this user is a OAuth User and which OAuth Token belongs to him? How can the user login without providing e-mail or password? (The user has no password) I guess I have to redirect him to the OAuth Provider again, but I don't want my user to grant access everytime he logs in.
Answer 1:
Though you can use the token provided by OAuth provider, you SHOULD NOT use it considering the risk that may arise exposing it to the public.
Instead you should securely save the token provided by OAuth provider into the database and use another token for authentication of further api calls. (you could use JWT)
Answer 2:
There are two types of systems
Which always uses OAuth provider for identifying user. (Ex. Tinder)
Which provides both OAuth Login and Traditional login/signup. (Ex. Quora, Instagram)
If you want your application to follow 2nd approach, you should ask the user to create password for the first time when the user logs in using OAuth provider.
This will allow the user to log into your application by both methods, traditional as well as OAuth
To identify users of your application, you should either use HTTP session or issue your own tokens. Do not use tokens generated by the OAuth2 provider - they are meant to be used just by your backend (in role of an OAuth2 client).
To use an external authentication in your application, you probably want to use OpenID Connect, not a bare OAuth2. OpenID Connect extends OAuth2 and it's meant for authentication instead of the rights delegation. Then you use an implicit flow (instead of authentication code grant) with scope=openid, your frontend app (HTML+JavaScript) gets an ID token signed by the OAuth2 provider. After successful signature verification, your backend can trust that the client is the one described in the ID token (in its "sub" field). Then you can either keep using the ID token or generate your own token.
Can someone shed some light on the use case for me. We wave users who will be signing in to third party client applications. Using OAUTH2 framework, the client app will redirect to our site to authenticate. From my undestanding, the Authorization server will return a access token and an id_token (OpenID Connect).
1) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go back into the client application hours later, do they still have go through the whole redirect to our /authorization endpoint to re-authenticate?
2) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go to our site, do they have to login again to authenticate?
Basically, does OpenID Connect over OAUTH2 allow a user to sign in once and then not have to sign in again after subsequent visit to the third party app or our app?
Thanks.
It depends on two things:
a. if the client application maintains a session and that session has not expired yet, the user won't be redirected at all
b. in case the client session timed out, the user will be redirected but if the IDP still has an authentication session running, the user will not have to authenticate and will be sent back immediately to the client app with a new token.
It depends on the IDP session existence/timeout again
Essentially an Identity Provider authenticates users and decides how to do that. It can prompt for credentials but can also create and maintain authentication sessions for the user for (typically) a limited period of time which allows for true Single Sign On (SSO).
Also note that this behaviour does not depend on the exact protocol at hand (OpenID Connect, OAuth or even SAML): it would work the same for any protocol that redirects a user to an Identity Provider in a federated SSO system.
In OpenID Connect, the session at RP typically starts when the RP validates End-User's ID Token. ID token consists of expiration time. So if the user just leaves (not logged out) and the id_token is expired when he access the RP, then the end-user needs to re-authenticate.
If the end-user logged out from the relying party and the OpenID provider supported logout mechanisms such as OIDC session management, OIDC front-channel logout or OIDC back-channel logout, then all RPs sharing the same browser session will be logged out (SLO). Then the end-user needs to login to the OP again to access the RPs.
I use OAuth2.0 of identityserver3 for SSO in company, I cannot understand how does the state parameter prevent the CSRF.
I have copied the attack flow as below:
1.Mallory visits some client's website and starts the process of authorizing that client to access some service provider using OAuth
2.The client asks the service provider for permission to request access on Mallory's behalf, which is granted
3.Mallory is redirected to the service provider's website, where she would normally enter her username/password in order to authorize access
4.Instead, Mallory traps/prevents this request and saves its URL(Callback Url)
5.Now, Mallory somehow gets Alice to visit that URL. If Alice is logged-in to the service provider with her own account, then her credentials will be used to issue an authorization code
6.The authorization code is exchanged for an access token
7.Now Mallory's account on the client is authorized to access Alice's account on the service provider
I can understand step 1 to step 4. But from step 5 I got some confusion. Accordding to my understanding, in step 5 Alice visit the Callback Url when she is logged-in, and then the server just use the authorization code to access the OAuth service provider to get an openid and access token in backend, and then Alice's browser just executing login with Mallory's account and access token.What is the relationship with Mallory's browser?
Could you explain it in detail please? Thank you for taking time to read my word!
I think steps 3 and 4 are not quite right. I've edited your example to show how I think the attack works.
1.Mallory visits some client's website (e.g. https://brilliantphotos.com) and starts the process of authorizing that client to access some service provider using OAuth (e.g. Acebook - as brilliantphotos.com allows its users to post pictures to their Acebook page)
2.brilliantphotos.com redirects Mallory's browser to Acebook's Authorisation Server requesting a redirect back to itself once auth is done.
3.Mallory is redirected to the Authorisation Server, where she enters her Acebook username/password in order to authorize access.
4.After successful login, Mallory traps/prevents the subsequent redirect request and saves its URL(Callback Url with an auth code related to Mallory) e.g.
https://brilliantphotos.com/exchangecodefortoken?code=malloryscode
5.Now, Mallory somehow gets Alice to visit that URL (maybe as a link on a forum post...) note that Alice may already be logged-in to brilliantphotos.com with her own account.
6.Alice clicks the link to brilliantphotos.com and the authorization code is exchanged for an access token (access to naughty Mallory's account). If Alice is logged in then brilliantphotos.com could conceivably associate Alice's account with the newly minted access token.
7.Now if Alice continues to use the brilliantphotos.com website, the client may inadvertently be posting pictures to Mallory's account on the service provider (Acebook).
If a state parameter was maintained by brilliantphotos.com then Mallory's state code would be bound to her browser but not Alice's. Therefore brilliantphotos.com would not be able to correlate the state code with Alice's browser session when Alice clicks on the malicious URL.
Besides iandayman's already great answer, you can also get some inspiration from this blog post, or at least you can take a look into its illustration.
PS: Credit goes to original blog author.
When I had resource owner grant type, I never needed to deal with the Consent Page but now I am trying to create SSO for my systems using OpenID Connect and I am very confused. /authorize endpoint always shows consent form for public apis (Facebook, Google etc) as this used to be the endpoint that was used for public apis most often.
With OpenID Connect, the /authorize endpoint seems to be doing the authentication and authorization, so how should I be handling the consent page. My ONLY thought is to check if the client has grant type password and if it does, do not show the consent form and just proceed the request with authorized = true. Is this a correct approach? There is nothing written in the specification on that (or at least I didn't see anything about it).
As noted in https://www.rfc-editor.org/rfc/rfc6749#section-4.3 for the Resource Owner Password Credentials grant the user credentials are presented in a call to the token endpoint, not the authorization endpoint. The latter is only used for the Authorization Code grant.
Upon sending the authorization request back to the client, it is up to the discretion of the Authorization Server to present a consent screen for release of the information. According to the spec the Authorization Server should present it in a consumer scenario but one may choose to disable it in an enterprise scenario. That would be an implementation specific option to configure in the Authorization Server.
Hi I'm just getting started on the v4 CTP so I can see me posting some basic questions as I get my head around it. I want to create a service provider so I'm looking at the WCF Oauth2
The first thing is when I go to login what is the format of the OpenID for use with the provided database? What is the process for this. I assume I'll get redirected to a screen where I put my password? And that interacts with the database?
Cheers, Chris.
The sample OAuth2 Authorization Server's database merely contains a couple of sample client entries so that the sample client can make requests. It has a users table that is automatically populated by each user who successfully logs in using their OpenID. So to your question regarding the "format of the OpenID" to use, any valid OpenID 1.1/2.0 identifier will work.
The OAuth2 authorization server sample doubles as an OpenID relying party in this respect, but its OpenID functions aren't the meat of the sample -- there are other sample OpenID RP sites that demonstrate more functionality in that respect. But being that OAuth2 auth server and OpenID RP are coupled in this way, the flow is that:
User visits OAuth2 Client site and indicates to the client that it may request access to user's data on the resource server.
Client redirects user to authorization server so the user may grant permission.
Authorization server prompts the user to log in, if not already logged in.
User enters OpenID
Authorization server redirects user to their OpenID Provider to log in using some credential (username/password, infocard, etc.)
OpenID Provider redirects user back to authorization server.
Authorization server sample then asks the user "do you want to share resource [x] with client [y]?" User confirms.
Authorization server records that user authorized client [y] to access [x] so that future requests from that client for that resource may be auto-approved without user intervention.
Authorization server redirects user back to Client with authorization grant.
Client receives the grant along with the user redirect and uses a direct HTTP request to the auth server to exchange that grant for an access token (and possibly a refresh token).
Client then includes the access token in HTTP requests to the resource server to access the user's private data.
I hope that helps.