We have a SSO system which is used by our web applications and we are planning to also write some new mobile/desktop applications. I have been reading about using oAuth 2.0 so a user can natively login using the app (using the password grant type), retrieve an access token and access functionality using the REST web services. The problem is all functionality will not be available within the app, in some cases we have to redirect the user to the web application via a browser. I have read we shouldn't pass the access token in a URL so is there anyway to use oAuth to login to the web application automatically without the user having to submit their username and password again?
Any advice would be much appreciated.
In the mobile app, you could create a nonce (a token that should be used no more than once). Then, add this to the URL when opening a link to the Web page. This token should have some sort of identifier in it. The Web app that serves that page should track these IDs to ensure that it's not sent multiple times (thus, making it a nonce). This would be independent of the OAuth-based authentication. So, a request might look like this:
GET /anything?nonce=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5N1Y2ZU9WWlo1VGpPR3dWIiwiY2xpZW50X2lkIjoibXktZ29vZC1tb2JpbGUtYXBwLTIyIiwiYXVkIjoiaHR0cHM6Ly9leGFtcGxlLm9yZy9wYWdlLXRoYXQtaXMtbm90LWluLW15LW1vYmlsZS1hcHAiLCJleHAiOjE1OTg3NTI0NDB9.JoDstXRnC23PE8ZCqk-U-IzSNp_cUYa12HbajI1KGlF-OwRR46QRC_V7brcGOVdo5_Aw1RdpssNWCVFiGDeTBc8wi1lIJW-rgEGH5J1qUi8rL1T-yfy3vdLGPYzJMtHvCeyoEjgmoYOtZcpPSQScBJSRvId3Hdu3QgwcelSwljkeNJbZRCnG25HIqJfC1Cjm9vqHhvUGqtzbgVBUPnICiI8EZyGe3SpH2P4SxctLcgzWad8zJeyPFki3yfBHpqQ3mBWy0BbVdjzgD0mj323q1LWHR4kNkrH7cUJgAg4PlWahOW7Q4qcT3CBJYNtlh008ARqK7XagEQKX45vv5TfSlk2q7Zy06RnV2XwZXfLpyh-ZfURpcsxEJ3O-4NY71XxEqUtEyuisjQdZx5m95uzSrzk75F-ruQ3KYIouiAOAUDuMtFwhwjF68VdDeC4Zwt2q3BHzMBBp-8k1bAXq8e4dmHz0Jbuo9R8MJ2zSrVK6is5nNtNoJvYoXgc0WTA8MFqBj316cT_ouu-U1nTL3GR5sJ_lxorhP6xz0CqNxNY_90-JwOUB0UibUryRiXt-SUPJga36pBQ8eO8--Xupx_WU7CDIFdFvnLgJahD-4KmZcga6wCoqd-KKw3H5-jtbit06XMrKkDiWjz2g4eYhPR6xipbnqyZaaCwtYN4mAMz86ug HTTP/1.1
Host: example.org
Accept: */*
When the JWT-encoded nonce is decoded, you can see this header:
{
"alg": RS256
}
and this body:
{
"jti": "97V6eOVZZ5TjOGwV",
"client_id": "my-good-mobile-app-22",
"aud": "https://example.org/page-that-is-not-in-my-mobile-app",
"exp": 1598752440
}
Now, the API could decide if the nonce is acceptable by:
Check that it's URL is the same as the aud (audience) claim
Check that the nonce has never been seen before (using the jti, JWT ID, claim)
Check that this resource should be possible for this client to request (using the client_id claim)
Check that the nonce wasn't created too long ago and is still valid (using the exp or expires claim)
The signature of the JWT is valid. This can be done using the public key of the client.
Doing like this could lead to a spaghetti of trust, however. To avoid this, your OAuth server could instead embed a nonce into the app's ID token, or allow the client to request new ones as needed (by performing token exchange e.g.). Then, the API only has to trust the OAuth server, and doesn't need to keep track of the client's public key. If you only have a handful of clients, this won't be hard to mange though.
Related
So, I'm developing an API using slim/slim and league/oauth2-server to manage the OAuth2 connection. OAuth2 will be useful because I will need to use Client Credentials grant between services.
Then, I'm also developing an hybrid app with React Native. This app will requires user login by using e-mail and password or connecting with another services (such as Facebook, Google, Twitter, etc).
And I'm confused about what OAuth2 flow to use for this case. Across the web are a lot of articles saying that Resource Owner Password Credentials is not safe anymore, and we should use instead Authentication Code with PKCE.
But I can't discover or understand how to apply Authentication Code with PKCE in a first party app, because all documentation talks about you will need the uses a browser to get authentication code in redirect_uri.
The flow I imagine is something like that:
User open the app, then insert your credentials username and password;
This screen will connect to API /request_token URI sending { 'grant_type': 'password', 'username': username, 'password': password, 'client_id': CLIENT_ID }, considering it as a public app we can't send client_secret;
The API validates credentials and returns some data such as { "access_token": access_token, "token_type": "JWT", "expires_in": LIFE_SPAN }, here we will use JWT to gerenate the access_token based in public/private key;
Authentication done, the app will store the access_token while it's alive and when it expires will do the flow to refresh_token.
My question: is it safe? Scott Brady did some "aggressive" article talking it's NEVER safe.
How apps does this things? When I use Instagram app, for example, they own the app and the API, I don't need a browser in the User Experience flow. Are modern apps using "Resource Owner Password Credentials" or "Authentication Code with PKCE"? There is a away to avoid insert browser in the flow while using "Authentication Code with PKCE"?
[EDIT] Possible Solution
As Gary Archer said "Auth Code flow with PKCE is recommended - along with logging on via the system browser", but we are not talking about grant permissions to access users data or third-party apps.
As a designer I don't agree that loggin in the first-party app owned by the same API owner requires a browser this is the not the User Experience we are looking for. And all apps we see such as Instagram, Facebook, Uber... we just put your username and password and we have access to your account.
What I will do is create a custom version of Authentication Code with PKCE removing the required_uri.
[EDIT:2] The New Flow
After a lot of search, I found some answers I think was interesting to adapt. As above, I removed redirect_url from flow. Look:
The flow starts in a login screen, when user give your credentials;
Client generates a code_verifier then hashes code_verifier to code_challenge and sends it to Authorization Server with following parameters:
response_type=code : indicates that your server expects to receive an authorization code.
client_id=xxxx : the client id.
client_integrity=xxxx : app integrity check for first-party app.
code_challenge=xxxx : the code challenge generated as previously described.
code_challenge_method=S256 : either plain or S256, depending on whether the challenge is the plain verifier string or the SHA256 hash of the string. If this parameter is omitted, the server will assume plain.
username=xxxx : username to authenticate.
password=xxxx : hashed version of password.
state=xxxx : a random string generated by your application (CSRF protection).
Authorization Server will validates user authentication, stores code_challenge and return the authorization_code with a client_token;
After receive the aauthorization_code and client_token, Client saves the client_token and immediately send authorization_code back to Authorization Server with following parameters:
grant_type=authorization_code : ndicates the grant type of this token request.
code=xxxx : the client will send the authorization code it obtained.
client_id=xxxx : the client id.
code_verifier=xxxx : the code verifier for the PKCE request, that the client originally generated before the authorization request.
Authorization Server will validates all data and, if everything is right, will return the access_token;
Client will set Authorization header with the access_token and always send client_token to every request, it will be only accepted with both values are right;
If access_token expires, then Client will do a request to refresh access_token and get a new one.
Now, I will reproduce this logic to PHP language. If everything goes right and I hope it does, I will be back with definitive answer.
[EDIT] Clarifications
I'm using OAuth2 to user connect with your third-party accounts (Google, Facebook, etc). But user also can log to a local account in my database. For this case, user doesn't need to grant anything at all. So, no makes sense send user to a browser to him does your login.
I wondering if, to this case, local accounts, we can use Resource Owner Password Credentials or it's more safe Authentication Code with PKCE (we already conclude it's a better approuch). But Authentication Code with PKCE requires redirect_uri, do I need uses this redirection to log users into a local account where they don't need to grant access?
Let's go then. After a lot research, I found some approaches that I will apply and may work correctly. So, first of all, here is the challenges:
You must never trust in clients running in client side. There's a lot of concerns about, your applications can be decomplied, modified, the users devices can be with a malware or connection may suffer with a man in the middle attacking (MITM)...
An API Server, even using OAuth2, will be able to only identify WHO is accessing the resources, but not WHAT is accessing. Therefore, any sensitive information will be dangerous, anything can steal it and uses it.
Resource Owner Password Credentials makes part of OAuth2 protocol for authorize resource owner to access your resources. So, it doesn't make part of authentication process and you will your ruin if you treat it like that;
By using ROPC grant type there is no way to know if resource owner is really making that request, what make "easy" a phishing attack. Reminds about "you know WHO and not WHAT". For last, this kind of grant makes easy for whatever thing assumes the user identity;
This grant type also goes against OAuth2 propourse, since OAuth seeks to avoid the password use to access resources. That why many people say to don't use it;
For reinforce, it's important to highlight ROPC is not authenticating user, but it just authorizing him to access the resource server.
And yes, ROPC allows for refresh tokens, but there are two issues: first, client needs resupply credentials each time needed to get a new token; second, if using a long-term access code, then things get more dangerous.
To prevent a malicious thing from arbitrarily using user credentials there are access tokens. They replace passwords and needed to be refreshed in short amount of time. That's why they are so much better than HTTP Basic Authentication.
That's why is recommended to use in modern apps the Authentication Code with PKCE, it provides all features and benefits of using OAuth2 protocol. But, here cames a long discussion and, even, problem for developer community:
To get an Authentication Code some user needs to make your login in a browser, grant access, redirect back to client and, soon, client will receive a code to exchange for an access token.
This scenario works good and NEEDS to be used for third-party apps. But, what if it is a first-party app? When you own the database with user data and you own the "trusted" app, redirect user doesn't make any sense. Right?
At this moment, my question is: how can I use the AuthCode (PKCE) flow without redirect user? And, again, it's important to highlight that talking about OAuth2 protocol is always the same that "to grant client to access resource server" (authorization, not authentication).
So the real question is: why Authorization Code needs a redirection at all? Then, I came with the following answer:
This flow requires to know client credentials and user consensus to turn back an authorization code.
That's why I was wrong in my edits. There's no change needed in OAuth2 protocol (sorry me for think different). For this reason, what OAuth2 needs is a authorization mediator, above your layer. Thus, the authorization code not will turn back to client, but to authorization mediator that, finally, will return it to client. Makes sense?
How it gonna work? Well, will be need 4 different "cores":
Authentication Server: will be responsible to authenticate user credentials and client identity. The main objective is to prove "WHO is the user and WHAT is connecting to get authentication";
Authorization Mediator (one layer above OAuth2): will validate client unique identity to ensure client/user is "know" and can get an access token;
Authorization Server: makes part of OAuth2 implementation, nothing change. Will authorize a client to get your authorization code, access tokens an refresh tokens;
Resource Server: will allow access resources through an access token.
And, then, security techniques we may consider:
API Key: each application (client) will have your own API Key with permissions scopes associated with those keys. By using it, you can gather basic statistics about API usage. Most API services use statistics to enforce rate limits per application to provide different tiers of service or reject suspiciously high frequency calling patterns;
Mutual SSL Authentication: by using this technique client and server exchange and verify each other's public keys. Once the keys are verified, the client and server negotiate a shared secret, a message authentication code (MAC) and encryption algorithms;
HMAC: API Key will be separeted into an ID and a shared secret. Then, as before, the ID is passed with each HTTP request, but the shared secret is used to sign, validates and/or encrypt the information in transit. The client and server will exchange the shared secret with algorithm such as HMAC SHA-256;
Protecting code application: using code obfuscators will make harder to locate and extract sensitive data from app, such as secret shared, api keys, public keys...
Handle user credentials: providing a simple method to user login and prove your identity. After insert valid credentials, server can return a user token (JWT) and emulates a user session with this.
Let's look at flow:
Part one: autheticating user and client;
User will type your credentials and be asked to prove your identity using your e-mail or mobile number, after Client will send user credentials (such as { email, mobile_number, hash ( password ), verification_method }) to Authentication Server route /login;
Authentication Server will validate user credentials and send a one-time password to user confirm your identity (for e-mail or mobile number as choose by user);
Then, user will insert the OTP received and client will send back to Authentication Server route /login-otp including the verification method (such as { otp, verification_method });
At the end, Authentication Server will return a { hash ( shared_secret ) } to be used soon.
Part two: authorizing API access;
When receive shared_secret Client will stores securely at mobile app, then it will ask for a authorization code using PKCE calling /auth with { response_type, client_id, scope, state, code_challenge, code_challenge_method }, Authorization Server will validate credentials and return an authorization code with no redirects;
Later, Client will exchange received code to an access token accessing /token, but it will need to send some extra data: { payload: { grant_type, code, client_id, code_verifier }, timestamp, hash ( some_user_data + timestamp + shared_secret ) };
Authorization Mediator will receive this request and validate trying to generate the same hash generated by user. And redirect all data to Authorization Server that will validate client_id, code and code_verifier responding with an access token;
This new access_token will return to Authorization Mediator and, after, to client granting access to API resources.
Part three: accessing resource server;
Client will each time needs send a call to API /api containing the Authorization header and some extradata with { timestamp, hash ( some_user_data + timestamp + shared_secret ) };
Authorization Mediator will validates the shared_secret hashes, call Resource Server validating access_token and return data.
Part four: refreshing access token;
After access token expires, Client will send a call to /refresh-token containing the Authorization header and some extradata with { payload: { grant_type, refresh_token, client_id, scope }, timestamp, hash ( some_user_data + timestamp + shared_secret ) };
Authorization Mediator will validates the shared_secret hashes, call Authorization Server and return a new fresh token access.
A visual image for this flow:
I don't think it is a perfect strategy, but it replaces Resource Owner Password Credentials to Authentication Code with PKCE and gives some extra security techniques. It's way better then a single and simple authentication method, preserves the OAuth2 protocol and mantaein a lit bit more hard to compromise user data.
Some references and support:
How do popular apps authenticate user requests from their mobile app to their server?
Why does your mobile app need an API key?
Mobile API Security Techniques
Secure Yet Simple Authentication System for Mobile Applications: Shared Secret Based Hash Authentication
Auth Code flow with PKCE is recommended - along with logging on via the system browser. Also the AppAuth pattern is recommended.
https://curity.io/resources/develop/sso/sso-for-mobile-apps-with-openid-connect/
It is tricky and time consuming to implement though - so you need to think about it - sometimes using a cheaper option is good enough. Depends on the sensitivity of data being exposed.
If it helps here are some notes for an Android demo app of mine, which also focuses on usability - and links to a code sample you can run:
https://authguidance.com/2019/09/13/android-code-sample-overview/
First of all, do not invent a OAuth grant simply because you need to adopt it in your application. It will make tings complex to maintain.
In your scenario you need to provide social login (ex:- Login via Google, facebook). This of course a desired functionality one must support. But it doesn't limit you from obtaining end user credentials through a custom registration process. There are many reasons for this, for example not everyone use social media or a Google account. And sometims people prefer to register than sharing user identifier of some other service (yes, this is the opposite end of social login).
So go ahead, provide social login. Store user identifiers when first login through external identity server (ex:- Google). But also, have a good old registration step with password and an email.
I'm currently trying to authenticate an angular 7 app with ADFS 2016 (using angular-oauth2-oidc). So far, it works pretty well. When I access the application, I'm redirected to ADFS login page where I enter my credentials and gets tokens.
Now, when the app calls the a web API, it send the access token in the request headers. The access token returned by ADFS looks like this:
{
"aud": "microsoft:identityserver:xxx",
"iss": "http://xxx/adfs/services/trust",
"iat": 1554561406,
"nbf": 1554561406,
"exp": 1554565006,
"apptype": "Public",
"appid": "xxx",
"authmethod": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
"auth_time": "2019-04-06T12:21:39.222Z",
"ver": "1.0",
"scp": "profile openid"
}
The issue is that the web API must know the ID of the user making the call (as there are some permissions defined at application level). I saw here that I can add claims to the access token, which I did. However, when reading articles on Internet, I read that apparently the access token is not supposed to be used to identify the user, so I don't know if it's correct to add a claim used by the web API to identify the user.
However, I read here that
The only user information the Access Token possesses is the user ID,
located in the sub claim.
But by default, ADFS does not provide a "sub" token. Is it correct if I add a "sub" claim by myself that contains the email address of the user or do I have to proceed in a different way?
Yes, access token is not supposed to be used to identify the user. But if you can get a user identifier into the access token and it's all you need to know about a user, then it's probably the easiest way. But it's implementation-specific for your auth server.
The standard way is to ask for the profile scope (which you did) and get information from the userinfo endpoint (see OpenID Connect RFC). If you use this way, you may want to cache the response, so you don't need to make this HTTP call on every client request.
If your backend API is used just by the Angular application and is not supposed to be called by third parties, you could also consider using the backend as the OAuth2 client which receives an authorization code and exchanges it for an ID token. Then, it can save the user's identity (read from the ID token) in a session and issue a cookie identifying the session. So there would be no need for the frontend to send a token on each request. This would make the backend stateful, but it might be easier to implement.
I write a rest api with yii2 and i am using oAuth2 , the problem is when user want login , client web application should send request to get token , request should contain client_id and secret_key and username and password in this case user can simply inspect element and click to network and see posted parameter to the server this means user can see client_id and secret_key.
client_id and secret_key are signature for each application and server can find out witch application use api.
how to handle this security issue?
It seems you have missed out one key element of OAuth 2.0, client type.
OAuth 2.0 defines two types of clients, public clients and confidentiatl clients.
2.1. Client Types
confidential
These are the clients which can protect a credential. They have the
full potential to use authorization code grant type, which obtain
token from backchannel request. Because they use backchannel to obtain
tokens, their credentials are never exposed to end user(via user
agent)
public
Clients which cannot protect credentials. For example SPA clients and
mobile apps comes to this category.
In your case, you seems to have a public client (user agent based application in broswer as it seems). In such case, you should set your client type to a public client. If this is not the case, you are not utilizing a proper back channel call from your web application.
Additionally, public clients which use authorization code flow can use PKCE to avoid authorization code theft attacks. Related RFC can be found from RFC7636
OAuth 2.0 has multiple workflows. I have a few questions regarding the two.
Authorization code flow - User logs in from client app, authorization server returns an authorization code to the app. The app then exchanges the authorization code for access token.
Implicit grant flow - User logs in from client app, authorization server issues an access token to the client app directly.
What is the difference between the two approaches in terms of security? Which one is more secure and why?
I don't see a reason why an extra step (exchange authorization code for token) is added in one work flow when the server can directly issue an Access token.
Different websites say that Authorization code flow is used when client app can keep the credentials secure. Why?
The access_token is what you need to call a protected resource (an API). In the Authorization Code flow there are 2 steps to get it:
User must authenticate and returns a code to the API consumer (called the "Client").
The "client" of the API (usually your web server) exchanges the code obtained in #1 for an access_token, authenticating itself with a client_id and client_secret
It then can call the API with the access_token.
So, there's a double check: the user that owns the resources surfaced through an API and the client using the API (e.g. a web app). Both are validated for access to be granted. Notice the "authorization" nature of OAuth here: user grants access to his resource (through the code returned after authentication) to an app, the app get's an access_token, and calls on the user's behalf.
In the implicit flow, step 2 is omitted. So after user authentication, an access_token is returned directly, that you can use to access the resource. The API doesn't know who is calling that API. Anyone with the access_token can, whereas in the previous example only the web app would (it's internals not normally accessible to anyone).
The implicit flow is usually used in scenarios where storing client id and client secret is not recommended (a device for example, although many do it anyway). That's what the the disclaimer means. People have access to the client code and therefore could get the credentials and pretend to become resource clients. In the implicit flow all data is volatile and there's nothing stored in the app.
I'll add something here which I don't think is made clear in the above answers:
The Authorization-Code-Flow allows for the final access-token to never reach and never be stored on the machine with the browser/app. The temporary authorization-code is given to the machine with the browser/app, which is then sent to a server. The server can then exchange it with a full access token and have access to APIs etc. The user with the browser gets access to the API only through the server with the token.
Implicit flow can only involve two parties, and the final access token is stored on the client with the browser/app. If this browser/app is compromised so is their auth-token which could be dangerous.
tl;dr don't use implicit flow if you don't trust the users machine to hold tokens but you do trust your own servers.
The difference between both is that:
In Implicit flow,the token is returned directly via redirect URL with "#" sign and this used mostly in javascript clients or mobile applications that do not have server side at its own, and the client does not need to provide its secret in some implementations.
In Authorization code flow, code is returned with "?" to be readable by server side then server side is have to provide client secret this time to token url to get token as json object from authorization server. It is used in case you have application server that can handle this and store user token with his/her profile on his own system, and mostly used for common mobile applications.
so it is depends on the nature of your client application, which one more secure "Authorization code" as it is request the secret on client and the token can be sent between authorization server and client application on very secured connection, and the authorization provider can restrict some clients to use only "Authorization code" and disallow Implicit
Which one is more secure and why?
Both of them are secure, it depends in the environment you are using it.
I don't see a reason why an extra step (exchange authorization code
for token) is added in one work flow when the server can directly
issue an Access token.
It is simple. Your client is not secure. Let's see it in details.
Consider you are developing an application against Instagram API, so you register your APP with Instagram and define which API's you need. Instagram will provide you with client_id and client_secrect
On you web site you set up a link which says. "Come and Use My Application". Clicking on this your web application should make two calls to Instagram API.
First send a request to Instagram Authentication Server with below parameters.
1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token.
You don't send client_secret, You could not trust the client (The user and or his browser which try to use you application). The client can see the url or java script and find your client_secrect easily. This is why you need another step.
You receive a code and state. The code here is temporary and is not saved any where.
Then you make a second call to Instagram API (from your server)
1. `grant_type` with the value of `authorization_code`
2. `client_id` with the client identifier
3. `client_secret` with the client secret
4. `redirect_uri` with the same redirect URI the user was redirect back to
5. `code` which we have already received.
As the call is made from our server we can safely use client_secret ( which shows who we are), with code which shows the user have granted out client_id to use the resource.
In response we will have access_token
The implicit grant is similar to the authorization code grant with two distinct differences.
It is intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret because all of the application code and storage is easily accessible.
Secondly instead of the authorization server returning an authorization code which is exchanged for an access token, the authorization server returns an access token.
Please find details here
http://oauth2.thephpleague.com/authorization-server/which-grant/
Let me summarize the points that I learned from above answers and add some of my own understandings.
Authorization Code Flow!!!
If you have a web application server that act as OAuth client
If you want to have long lived access
If you want to have offline access to data
when you are accountable for api calls that your app makes
If you do not want to leak your OAuth token
If you don't want you application to run through authorization flow every time it needs access to data. NOTE: The Implicit Grant flow does not entertain refresh token so if authorization server expires access tokens regularly, your application will need to run through the authorization flow whenever it needs access.
Implicit Grant Flow!!!
When you don't have Web Application Server to act as OAuth Client
If you don't need long lived access i.e only temporary access to data is required.
If you trust the browser where your app runs and there is limited concern that the access token will leak to untrusted users.
Implicit grant should not be used anymore, see the IETF current best practices for details. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18#section-2.1.2
As an alternative use a flow with response type code; for clients without possibility to securely store client credentials the authorization code with PKCE flow should be your choice.
From practical perspective (What I understood), The main reason for having Authz code flow is :
Support for refresh tokens (long term access by apps on behalf of User), not supported in implicit: refer:https://www.rfc-editor.org/rfc/rfc6749#section-4.2
Support for consent page which is a place where Resource Owner can control what access to provide (Kind of permissions/authorization page that you see in google). Same is not there in implicit . See section : https://www.rfc-editor.org/rfc/rfc6749#section-4.1 , point (B)
"The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request"
Apart from that, Using refresh tokens, Apps can get long term access to user data.
There seem to be two key points, not discussed so far, which explain why the detour in the Authorization Code Grant Type adds security.
Short story: The Authorization Code Grant Type keeps sensitive information from the browser history, and the transmission of the token depends only on the HTTPS protection of the authorization server.
Longer version:
In the following, I'll stick with the OAuth 2 terminology defined in the RFC (it's a quick read): resource server, client, authorization server, resource owner.
Imagine you want some third-party app (= client) to access certain data of your Google account (= resource server). Let's just assume Google uses OAuth 2. You are the resource owner for the Google account, but right now you operate the third-party app.
First, the client opens a browser to send you to the secure URL of the Google authorization server. Then you approve the request for access, and the authorization server sends you back to the client's previously-given redirect URL, with the authorization code in the query string. Now for the two key points:
The URL of this redirect ends up in the browser history. So we don't want a long lived, directly usable access token here. The short lived authorization code is less dangerous in the history. Note that the Implicit Grant type does put the token in the history.
The security of this redirect depends on the HTTPS certificate of the client, not on Google's certificate. So we get the client's transmission security as an extra attack vector (For this to be unavoidable, the client needs to be non-JavaScript. Since otherwise we could transmit the authorization code via fragment URL, where the code would not go through the network. This may be the reason why Implicit Grant Type, which does use a fragment URL, used to be recommended for JavaScript clients, even though that's no longer so.)
With the Authorization Code Grant Type, the token is finally obtained by a call from the client to the authorization server, where transmission security only depends on the authorization server, not on the client.
I am writing a web app, "B", that interfaces through a REST API with another web app, "A", that I wrote and control.
I would like for a user that is logged into A to be able to perform actions on B that use the API to communicate with A. My best option looks like OAuth, but I want the experience to be seamless, and OAuth requires that the user consent before an access token is granted.
Is OAuth a good solution for this situation? Is there a better alternative?
If I do use OAuth, can I pre-authorize consent by trusting the Consumer Key?
You can do XAuth, which is an extension on OAuth. It uses the same principles of request / access tokens and secrets, but allows you to exchange a username / password combination for a access token.
We use it like:
User logs in onto our iPhone app
iPhone creates OAuth request token request, plus sends username + password over HTTPS
Validate request (secrets etc., + username / password), generate request token, and exchange request token for access token. (This step is fully on the server, so the server does the exchanging).
Access token is returned to the user
iPhone app uses normal OAuth protocol + access token to communicate to server
Same way Twitter is doing it for apps that don't allow for an easy OAuth authentication page.
Eran Hammer-Lahav says,
The user should be in control of their
resources, but if this is just a case
of one provider spread over multiple
domains, I see no harm in skipping
granting access to a client which is
essentially owned by the same entity.
Take a look at the oauth2 client credentials flow.