I am not a programmer (more of a scripter) but wondered if someone could clear up the following for me please as I am learning out oAuth2
If you have a separate authentication server (e.g. google, facebook etc) and a separate resource server (some other site entirely)
when the 'client application' presents the 'access token' to the resource server (to get access to the users data). How does the resource server know it can trust the access token?
In other words is the access token x509 signed and converted to base64 or something like that so when the resource server receives the token it can convert back to json/xml or what ever format it is in then check the signature?
if so that would require the resource server to trust the authentication server in advanced of the access token being presented
I would be grateful if someone could clear this up for me please
Thank you
__CAshtones
In this case, instead of access token, authorization code is used.
This is happening when a Facebook log in is clicked on an XYZ website.
XYZ website redirects to Facebook login page together with an XYZclientID(XYZ should be already registered under Facebook as a developer)
Facebook identifies that XYZ(using XYZclientID) wants to authenticate ABC person
ABC person log in to facebook.
Facebook issues an authorisation code(for ABC+XYZ combination) and redirects back to XYZ website.
XYZ uses this authorisation code + XYZclientID + XYZclientSecret to get a bearer token
Facebook validates the secret and issues a bearer token(linked to ABC person)
XYZ uses this bearer token to retrieve details of ABC person. (It cannot be used to retrieve data of DEG person)
Facebook give the email & other personal details of ABC to XYZ and XYZ shows that ABC is logged in.
More elaborated here :
https://www.scienceabc.com/innovation/oauth-how-does-login-with-facebook-google-work.html
Related
The implicit grant is a simplified authorization code flow optimized
for clients implemented in a browser using a scripting language such
as JavaScript.
The resource owner password credentials (i.e., username and password)
can be used directly as an authorization grant to obtain an access
token.
(https://www.rfc-editor.org/rfc/rfc6749#section-1.2)
My question is about understanding how these two grant types are different?
Important to understand here is the way and place you enter your credentials.
Implicit
Your app is https://example.com and for authentication, you are going to https://auth.some-domain.com (or even https://auth.example.com). After successful authentication, user is redirected to https://example.com/some-callbackurl?#token=token-value.
Points to be noted: Redirection and token in URL
Resource Owner Password flow
Your app is https://example.com and for authentication, you are going to https://example.com (or https://example.com/login). After successful authentication, user is redirected to https://example.com/home.
Points to be noted: No redirection and no token exchange in URL
Basically if you are owning the app (client app, server app, auth app) then this is something you would do. Basically you are the one who is in charge of authentication - not a third party app. You trust your client app.
https://example.com/login gets credentials from user and does a HTTP REST POST (for example) call and get a response as token (and refresh token - optionally). It saves it in localStorage or cookie and then redirects to home page or whatever page it has to redirect to.
No redirection happens in exchange.
As you quoted, the "Resource Owner Password Credentials Grant" is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system. An example is Facebook application - Facebook trusts their app that is installed on the device.
Thus, client-app does not have to be registered in the auth-server. As you can see in the request the client_id is not transferred as a param. In addition, the flow is simpler - the access token is retrieved within a single request.
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.
I have an application that currently integrates into my merchant account using my access token. Early discussion with neighborhood merchants indicates some positive interest. I want to integrate OAuth support so that I can try to get traction with those merchants.
Though https://docs.connect.squareup.com/api/connect/v1/#navsection-oauth has information, I seek some additional clarification.
(i) Access using https redirect-url is denied at Square Connect Authorize has an answer "By default the OAuth flow is disabled for applications which is why you are seeing the "Authorization not allowed" failure. If you wish to enable OAuth flow for your application then you need to contact Square." #SquareConnectSupport: I have sent an email to Developer#Square, please let me know what else do I do.
(ii) Here is how I think it will work - the OAuth integration (Please confirm)
User types in browser say "mysnow.com/square"
The Handler at "mysnow.com/square" allows user to type in an ID this ID is local to mysnow
Then the Handler at "mysnow.com/square" directs the merchant to https://connect.squareup.com/oauth2/authorize along with my application id, permissions and redirect url.
The handler then receives a notification code with AuthZ Code at the redirect URL previously provided.
Next the handler obtains the Access token (using the AuthZ code)
Finally, the handler then saves the ID, the AuthZ code , the relevant Access Token and the date/time stamp (when the token was obtained) as a tuple in a safe data store.
(iii) Using the Access Token
When there is need to access merchant data of given ID, then use the ID to get the Access Token. Use this Access Token to manage the permitted data (based on permission)
Renew the access token periodically.
(iv) For testing purposes, I create few test/dummy merchants? Or do you have dummy merchant accounts that I can use for testing.
You can authorize up to ten merchants through the OAuth flow without approval from Square, which should be enough to get your integration running and tested. If you would like to make it more broadly available, you will need to contact Square about getting the app in the Square App Marketplace.
That looks essentially correct. The best practice for OAuth is something like this:
Merchant visits your landing page (e.g. mysnow.com/square) and clicks an action to start using your square integration.
Merchant's browser is redirected to the OAuth page (https://squareup.com/oauth2/authorize?client_id=YOUR_CLIENT_ID&scope=LIST_OF_OAUTH_SCOPES_YOU_NEED)
Merchant authorizes your application to access their data and is redirected back to your site. In the URL is an authorization code
Your backend makes an API call to Square to exchange the authorization code for an access token. It then uses that access token to look up information about the merchant and pre-populate fields of your signup form (e.g. you can get name, email, etc)
With a partially populated signup form on your site, merchant is prompted to complete their registration with your service.
There isn't really a way to create "dummy" merchants, but you can sign up for multiple merchant accounts with the same identity information, as long as you use a different email for each one. If you have GMail, you can do "you+someword#gmail.com" and the mail will be redirected to "you#gmail.com", so you don't need to create a bunch of email accounts to have unique email addresses.
Let's say, i want to develop a rest api implementation and use OAuth 2.0 with authorization_code grant. I will have apps, users, access_tokens etc. I just couldn't imagine only one scenario. When a user permits an app to use it, my auth server will redirects him to app site with auth code and then the app will post it with its client_id to fetch access_token. So, how can i link this access_code to the user? At last, the app will want to access to some resource about THE USER and will post the access_code which my auth server created to access it. Or just the app should store to link between access_code and the user id(but how can it determine the user, it is an another question).
The Authorization server have to provide a service to give the resource server user information but using access_token so the resource server can get user Id and other information to use it, example of it is using login with FB or google, it is providing user information to the 3rd party want to authenticate this user.
Background:
MySite.com - my website
ParentSite.com - website of a client
company (which will have OAUth
provider module on it)
MySite Module - a module which I have created which will be installed on ParentSite.com
and which will allow users of
ParentSite to be redirected to MySite (via
OAuth). I have full control over what
I do in this module. I will be displaying links that users will be clicking on and expecting to reach MySite and be fully logged-in.
My understanding of a standard OAuth setup:
Users go to a specific URL on MySite.com for OAuth login into ParentSite.com.
The MySite app retrieves an OAuth "request token" from the ParentSite.
The browser is redirected to the ParentSite.com site, asking to confirm that the MySite App is allowed to see the user's information.
The user confirms. (*)
The browser is redirected to the MySite.com, which now has an OAuth "access token" for the user.
The Client App sends a REST request back to ParentSite.com, using the OAuth access token from step 5 as authentication, requesting the user's identity information (e.g. ParentSite user ID, name, email address).
The ParentSite validates the OAuth access token and returns the user's information to the Client App.
My scenario is slightly different, the differences are:
A. The users are users of ParentSite.com and are at ParentSite.com and need to be seamlessly connected to MySite.com when they click on certain links on "MySite Module"
B. I would like the user-authorization step (step 3 and 4) to be automated, ie, no prompting of the user.
Q1: What do I have to do at "MySite Module" to enable all this? (detailed answer needed please!)
Q2: How can I automate step 3 and 4?
Ok, let me get this straight. Clicking on something in "parentsite" opens something on "mysite", "mysite" then tries to manipulate stuff at "parentsite" and therefore needs to be authorized to do so? If I am wrong, please disregard this answer.
I am also assuming that you have control over parentsite.com - otherwise I can not see a way for you to accomplish what you seem to need.
Part 1.
First of all, mysite needs a consumer key and secret.
Part 2.
Since calls to mysite are issued directly from parentsite, you can issue an access token directly within the parentsite service (you already know which user is logged in). So when accessing mysite.com - simply send it the access token and secret it needs.
Part 3.
Ok, so now mysite.com should have consumer key/secret and access key/secret and should be able to do stuff with parentsite.com.
Keep in mind that this really is outside the oAuth specification, but perfectly doable.