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/
Related
Apologies for the oddly worded title, however I could not come up with a better one.
My application should be able to perform a limited set of actions on an Enterprise Google Apps system. Users submit requests to the application, the application interprets these requests and then makes requests to Google resources as necessary.The point is that users, who normally do not have permissions to access/modify the google apps resources, will be able to use this application to do so in the limited ways that it allows.
My problem lies in the apparent fact that the OAuth2.0 authorization flow seems designed to allow third party client applications to authorize themselves as the user and access/modify the user's google resources, rather than a global administrator's. In other words, a normal API key type deal. Unfortunately it seems that Google's AdminSDK will only work with OAuth2 authorization.
Is there a way to use Google's AdminSDK API with OAuth2 (permanent access token, maybe? API key?) to do what I want? Or is there a different API I should be trying? The now-deprecated Provisioning API seemed to be able to do this.
I feel like there should be a way for the application to just pull something out of a secrets.json or secrets.yml, include that in the API authorization request and have Google servers recognize and grant access to the application without the user ever needing to see what's going on.
For the record I'm using Ruby on Rails, though I don't think that affects the question very much.
How to secure access to rails server which provides REST API access.
We use Devise for authentication.
Our Rails app talks to another Rails server (Service App) and we would like the user to authenticate before accessing the Service App. Should I do it via device authentication token. Kindly advise? What should be done at the service level
https://github.com/plataformatec/devise
https://github.com/lynndylanhurley/devise_token_auth
Well, it depends of your app architecture.
You can use devise to authenticate users at REST API.
But if your Service App is for internal use only, for example it provides data only for another app, you can restrict access by ip, or Basic HTTP auth.
My opinion, that devise is good only for authorising end-users, but not services.
In my opinion, this question is highly opinion based as it stands at the moment.
What is the purpose of the Service App? Does your Rails app consumes frequently from the Service App? Or the other way around? Is it just for logging purposes, like statistics or tag-like resources or critical data like credentials?
From my rule of thumb, if an actual end-user needs to access it to modify a resource (POST, PUT, DELETE) I'd go for token based authentication. If it only needs to read, I might just go with just Basic or none at all, depending on the context.
Either way, I would consider twice if Devise is the precise tool for your own scenario. More than few times I have found myself writing more to actually modify Devise than it would be necessary if I implement my own authentication system. It's not that hard and you learn a lot!
When using OAuth (2) I need a redirection endpoint in my application that the OAuth-offering service can redirect to, once I have been authenticated.
How do I handle this in a single page application? Of course, a redirect to the OAuth-offering service is not nice here, and it may not even be possible to redirect back.
I know that OAuth also supports a username / password based token generation. This works perfectly with an AJAX call, but requires my single page application to ask for a username and password.
How do you usually handle this?
Most of the time, a redirect is okay even for SPA because users don't like to put their X service credentials on any other website than X. An alternative will be to use an small popup window, you can check what Discourse does. IMHO a redirect is better than a popup.
Google Some providers support the resource owner flow which is what you described as sending username and password, but this is not nice. These are the problems I see:
Asking google credentials to users in your site will be a no-go for some users.
The resource owner flows need the client_secret too and this is something that you must NOT put in your client side javascript. If you instantiate the resource owner flow from your server-side application and your application is not in the same geographically region than the user, the user will get a warning "hey someone is trying to access with your credentials from India".
OAuth describes a client-side flow called implicit flow. Using this flow you don't need any interaction in your server-side and you don't need the client_secret. The OAuth provider redirects to your application with a "#access_token=xx". It is called implicit because you don't need to exchange authorization code per access token, you get an access_token directly.
Google implement the implicit flow, check: Using OAuth2 for Client-Side apps.
If you want to use the implicit flow with some provider that doesn't support it like Github, you can use an authentication broker like Auth0.
disclaimer: I work for Auth0.
What José F. Romaniello said is correct. However, your question is broad and thus I feel any offered conclusions are just generalities at this point.
Application state
For example, without knowing how complex your application state is at the time you want to let your users log in, nobody can know for sure if using a redirection is even practical at all. Consider that you might be willing to let the user log in very late in his workflow/application usage, at a point where your application holds state that you really don't want to serialize and save for no good reason. Let alone write code to rebuild it.
Note: You will see plenty of advice to simply ignore this on the web. This is because many people store most of the state of their application in server-side session storage and very little on their (thin) client. Sometimes by mistake, sometimes it really makes sense -- be sure it does for you if you choose to ignore it. If you're developing a thick client, it usually doesn't.
Popup dialogs
I realize that popups have a bad rep on the web because of all their misuses, but one has to consider good uses. In this case, they serve exactly the same purposes as trusted dialogs in other types of systems (think Windows UAC, fd.o polkit, etc). These interfaces all make themselves recognizable and use their underlying platform's features to make sure that they can't be spoofed and that input nor display can't be intercepted by the unprivileged application. The exact parallel is that the browser chrome and particularly the certificate padlock can't be spoofed, and that the single-origin policy prevents the application from accessing the popup's DOM. Interaction between the dialog (popup) and the application can happen using cross-document messaging or other techniques.
This is probably the optimal way, at least until the browsers somehow standardize privilege authorization, if they ever do. Even then, authorization processes for certain resource providers may not fit standardized practices, so flexible custom dialogs as we see today may just be necessary.
Same-window transitions
With this in mind, it's true that the aesthetics behind a popup are subjective. In the future, browsers might provide APIs to allow a document to be loaded on an existing window without unloading the existing document, then allow the new document to unload and restore the previous document. Whether the "hidden" application keeps running or is frozen (akin to how virtualization technologies can freeze processes) is another debate. This would allow the same procedure than what you get with popups. There is no proposal to do this that I know of.
Note: You can simulate this by somehow making all your application state easily serializable, and having a procedure that stores and restores it in/from local storage (or a remote server). You can then use old-school redirections. As implied in the beginning though, this is potentially very intrusive to the application code.
Tabs
Yet another alternative of course is to open a new tab instead, communicate with it exactly like you would a popup, then close it the same way.
On taking user credentials from the unprivileged application
Of course it can only work if your users trust you enough not to send the credentials to your server (or anywhere they don't want them to end up). If you open-source your code and do deterministic builds/minimization, it's theoretically possible for users to audit or have someone audit the code, then automatically verify that you didn't tamper with the runtime version -- thus gaining their trust. Tooling to do this on the web is nonexistent AFAIK.
That being said, sometimes you want to use OAuth with an identity provider under you control/authority/brand. In this case, this whole discussion is moot -- the user trusts you already.
Conclusion
In the end, it comes down to (1) how thick your client is, and (2) what you want the UX to be like.
OAuth2 has 4 flows a.k.a. grant types, each serving a specific purpose:
Authorization Code (the one you alluded to, which requires redirection)
Implicit
Client Credential
Resource Owner Password Credential
The short answer is: use Implicit flow.
Why? Choosing a flow or grant type relies on whether any part of your code can remain private, thus is capable of storing a secret key. If so, you can choose the most secure OAuth2 flow - Authorization Code, otherwise you will need to compromise on a less secure OAuth2 flow. e.g., for single-page application (SPA) that will be Implicit flow.
Client Credential flow only works if the web service and the user are the same entity, i.e., the web service serves only that specific user, while Resource Owner Password Credential flow is least secure and used as last resort since the user is required to give her social login credentials to the service.
To fully understand the difference between recommended Implicit flow and Authorization Code flow (the one that you alluded to and requires redirection), take a look at the flow side-by-side:
This diagram was taken from: https://blog.oauth.io/introduction-oauth2-flow-diagrams/
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.
I would like to offer authenticated API access to my web app. The consumers of such a service are typically other web sites/services.
What would be the best method of authenticating these users? OAuth, openID, http authentication?
As so much in our line of work, the answer to "which is best?" is "it depends." :)
HTTP Authentication - If you're already letting clients log in to your service via an ID and password, you'll probably only have to do minimal work to get this to play nicely with your API. If your API is basically mono-purpose and doesn't require detailed permissions, you can get something working fairly quickly here.
API Token - If you want clients to be able to authenticate easily without providing a password (think companies that build a service that interacts with your API; maybe the IT dept. doesn't want the dev. team knowing the passwords; etc.), then attaching a random API token à la GitHub to the user account is probably the quickest way to go. As a bonus, you can supply a method for regenerating the API token without having to change the account password.
OAuth - If you have multiple permissions or want finer-grained control over how and when a client can access your API, OAuth is a pretty good bet (OAuth2 is much easier to work with, IMO, and supports multiple methods of obtaining an access token). Furthermore, many languages have libraries, gems, etc. that will allow them to simplify the OAuth workflow.
I would say the "best" method is oAuth. It's more flexible and it can be application independant for further uses .
I am using oAuth to authenticate my clients (applications).
;)