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.
Related
With OAuth 2.0 PKCE Flow for Installed App (e.g. a desktop app/cli/client library), it seems that nothing is preventing an attacker to:
obtain client_id by using the original app (client_id is public and can be easily copied from browser bar/source code)
make a fake app to mimic original app
use the fake app to seduce the user to grant access and thus obtain a refresh token which essentially means full access within requested scopes
Without PKCE, it's hard to fake an app and obtain a refresh token because that would require an attacker to obtain client_secret. It seems to me that, although PKCE offers security improvements over implicit flow, it makes it so much easier to masquerade authentic apps that use OAuth 2.0?
I'm using googlecloudsdk (gcloud), it seems that it has client_id (and even many client_id/client_secret pairs) hard coded into the source code, which is distributed to the client. I doubt there's anything to stop attackers to fake gcloud and thus gain access to user's GCP environment (for proof, run gcloud auth login and it will show you the url in the console that an attacker needs.) Could anyone clarify/help me to understand what's going on?
Private URI schemes are probably the best you can do on desktop but are not perfect as you say. It is what I use for my Desktop Code Sample, but ideally I'd also like to resolve the above concern.
For mobile you can use Claimed HTTPS Schemes to solve the problem - see the answer I added to the post sllopis sent.
I would be aware of Updated OAuth 2.1 Guidance for Native Apps - see section 10 - but I don't think you can fully solve this problem.
It is expected that end users are careful about desktop apps they install, to reduce risks for this scenario. Hopefully operating system support will enable better cryptographic options in future.
Just wanted to follow up on this because I had the same question myself, but also answered it myself and I wanted to add something that wasn't said here:
When you set up the application on the oauth2 server, you have to set up a number of redirect_uris, allowed places to return to after authorization is complete. This means that someone who creates a phishing attack like the one you described cannot return to their own app after login, and will never receive the code.
There is a separate attack where you try and return to a legitimate app from an illegitimate app, however this is solved by the inclusion of the state variable.
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/
<context> I got frustrated yesterday and posted a flame question which was quickly (and appropriately) closed and deleted by my fellow SO cohorts. Yahoo! turned off its standard PlaceFinder API endpoint and replaced it with a paid service. That's not the part that frustrated me though, it was mostly the fact that they changed their access model to require OAuth. One of the closers of my question commented something to the effect of:
you didn't keep an eye on deprecations of API's you depend on, OAuth
is better for users, suck it up.
While I could argue the facts of my API-watching by again blaming Yahoo for having broken links when they first announced the API deprecation back in October / November of last year, I think it would be more productive to try and turn this into an intelligent question. </context>
I have used OAuth. I like OAuth. Not only does it let you authenticate users and simplify sign ons to your application, it lets you ask for authorization to access that user's data from other apps. But PlaceFinder data is not private user data. It is for known place names and global identifiers (WOE ID's) that can be shared by everyone.
This morning I gave Yahoo! BOSS GEO my credit card information and started spiking up an OAuth API consumer to test it out. I started with DotNetOpenAuth, which I have used in the past. I read through Yahoo!'s OAuth guide and created a DotNetOpenAuth.OAuth.ServiceProviderDescription instance with all of Yahoo!'s OAuth 6.1, 6.2, and 6.3 endpoint URL's. I then went about trying to figure out how to use DotNetOpenAuth.OAuth.WebConsumer to hit the PlaceFinder API and start giving money to Yahoo!.
But it didn't work. I had to overcome a lot of cognitive dissonance, and in the end, either a limitation of the popular and widely-used DotNetOpenAuth library itself or a possible misuse of OAuth. When I finally realized that the BOSS documentation was separate from the BOSS GEO documentation, and found a C# code sample that worked to consume Yahoo!'s PlaceFinder API, I discovered where all of that dissonance was coming from.
Yahoo!'s PlaceFinder API, while it uses OAuth, does not require an Access Token to get at the API's endpoints or data. When you send a PlaceFinder request, you send all of your app's information (consumer key and secret), along with the timestamp, nonce, and signature to the PlaceFinder endpoint itself. When I used OAuth in the past, these elements were sent to the 6.1 endpoint to obtain a request token. You could then use that to authenticate / authorize the user (6.2) and obtain an Access Token (6.3) to make further requests.
Here's the limitation in DotNetOpenAuth that I can't overcome so far, so if I'm being ignorant and doing it wrong here please tell me. In the sample C# code on Yahoo!'s site, they are not using DotNetOpenAuth. Instead they have an OAuthBase class that you can use to generate a nonce, timestamp, and signature. But they send empty strings for the access token and secret. I tried doing this with DotNetOpenAuth, but it won't let you construct any requests with a null or empty access token.
So the question: Is this an inappropriate use of the OAuth standard? If not, is there a limitation in the DotNetOpenAuth library that makes it impossible to send unauthorized requests to endpoints other than for a RequestToken (6.1)? If the answer to both of these is no, how could you use DotNetOpenAuth to request PlaceFinder data without having to send an access token or secret?
This is a great question. I think oAuth provides BOSS developers with two benefits
Since you sign up for BOSS once and can then use that key for multiple services, the BOSS team wanted to have the flexibility to offer more services that needed tokens in the future. Starting with oAuth right from the get go allowed that flexibility.
The team wanted to ensure that keys are not sniffed out during network communication. Since requests are signed and actual keys are not passed, we can ensure that no sniffing happens.
Regarding your question on DotNetOpenAuth, I recommend asking on the BOSS Y! group (http://tech.groups.yahoo.com/group/ysearchboss/) since we have a number of folks who have written in C#, VB.Net who can advise you. In fact it is well known that the VB.Net oAuth library (http://oauth.googlecode.com/svn/code/vbnet/oAuth.vb) has some issues with it.
There's two types of oAth that yahoo uses. One requires a key, one doesn't. You probably want the one that doesn't for general API use. Just add the secure protocol http:// -> https:// and then place /public/ in an appropriate spot of the old url like
https://somePartOfURL/public/otherPartOfURL
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.