I have one main Asp.net MVC application, I also have a help site and quite a few internal apps (that I need to build - reporting, stats, support tickets).
Question: Can OAuth be used in this way? i.e. a user can be authenticated to use all apps (if they have access to that app)?
Ideally all or most of the other apps will be implemented in Ruby or Node.js - so I am hoping I can achieve this with OAuth.
As long as all of your apps run under the same top level domain, it should not be strictly neccessary to use OAuth or similar to obtain a shared session. Instead you could rely on a plain session cookie. You could run some kind of middleware in between your app and the user.
Only if the main app is providing a REST API that you may want to use on various client apps, where some of them run in external environments / domains, making use of OAuth may be relevant.
Related
I have two client applications : Asp.Net MVC Core web app and an Android native mobile app, and an IdentityServer4 Server as an OpenID Server`.
I know that I have to create two client records for both of them (in the IS4's Clients table) :
a Hybrid Flow for the web app
a Hybrid/Authorization Code + PKCE for the native mobile app
But I'm wondering if I can create only one Client info for both of them or not?
I think you should create one client definition for each client, so you better can separate them and better evolve them as needed over time. Also makes it easier to separate them in the logs for example.
A question is however why/if you really need to support the hybrid flow? I think both clients only need to use the authorization code flow.
If you want to follow OAuth 2.1, then there are only two flows to use, either authorization code flow or client credentials flow. All other flows are not recommended due to various security issues. See https://oauth.net/2.1/
Tore's answer gives good reasons to keep those clients separated. If you're still not convinced, I would turn the question around - why do you want to have one logical client data used by two separate clients? This will cause some weird issues in the future. For example, at some point you might want to rate-limit one of those clients, or change client authentication method, or even block one of them completely. You will have to do it for both your apps if you don't create a separate client.
From the security point of view, there is a good reason to keep those two separated: the web client can be a confidential client with a secret assigned. The mobile client will be a public client, without a secret*. This is a solid reason not to mix those two, as you will lower the strength of your security considerably.
*In fact, best practice would be to use DCR and register a new client for each device where your app runs.
I am creating a new React SPA. Users of a legacy app need be able to use the new app without re-authenticating. So I need to support SSO.
It's important to note that it is also required that users of other (currently unspecified) apps should also be able to use the new app without re-authenticating, so whatever approach I take needs to be sufficiently decoupled to potentially allow this.
The legacy app supports authentication via Shibboleth, the new app currently has no authentication method, but uses JWT for authorisation.
I'm wondering if anyone has any experience of such a scenario? It seems to me that I probably need to be create an OAuth2 authorisation server for the new app to talk to and I need to somehow bring Shibboleth into the mix for the authentication, maybe with the authorisation service acting as a Shibboleth Service Provider. Googling around hasn't revealed much useful info.
Is what I've described along the right lines? I know it's very high level and woolly, but I'm really not sure of the approach to take. Any advice, information or experience in this area would be gratefully received!
GOALS
It's a little bit of a subjective question, but the main goals are usually as follows:
Focus on building your UI and API security in a future facing manner
Also provide good Login Usability
Also deliver on non functional requirements such as availability / reliability
AUTHORIZATION SERVER
On the first point, the modern option is to integrate UIs and APIs with an Authorization Server - perhaps as in My Tutorial. Your architecture is then good, but the migration is not trivial.
FEDERATING TO SHIBBOLETH
The Authorization Server can then redirect to Shibboleth and talk SAML2.0 to achieve Single Sign On, as you suggest. It is a complex solution though, and may be a backwards step in some ways.
AVAILABILITY
This is usually a big concern, and most companies use a cloud provider such as Azure / AWS due to its high availability / low maintenance / low cost. Would this be a better option for you?
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/
I'm working on an appengine app which uses OAuth. Naturally, I'm dealing with multiple versions of the app simultaneously - a local version for development, a staging version and a deployment version.
To work with these, I need three separate sets of OAuth consumer keys/secrets as the callback on authentication is defined on the provider's site.
I was wondering if there are ways for providers to provide multiple keys/secrets for a given app - this would seem to make more sense than setting up a new app each time. (Of course, it requires the provider to implement this, but it seems a natural thing to implement and I haven't seen it).
More generally, what standard approaches are used to deal with this - my guess is register multiple apps and have logic in the app to determine if it's in development mode, staging or deployment. Any thoughts welcome.
I find this to be one of the most annoying parts of being an OAuth API client developer. There is no reason why providers should not allow developers to register redirection (callback) URIs for testing.
The standard approach I've seen is to allow you to whitelist one or more domains for callback / redirection. Facebook has some crazy setup where they let you "register" multiple domains by using different domains for the various links in the application profile. I did not have much luck with that. Twitter is one of the better implementation for that, letting you register multiple domains.
In OAuth 2.0 (draft 18 or newer), this topic gets much better treatment. Registration of the full URI is recommended, with the ability to register multiple callbacks and select the one you want to you dynamically at request time.
The main aspect to consider is how you want to handle permissions with a staging setup? Do you want to be able to reuse existing approvals or want to keep those separate? Also, if the API provides special client-only calls (such as client storage or management tools), do you want the stage version to share it or keep its own (so that testing will not mess up production).
At the end, providers should provide a complete development environment and that includes testing facilities for API clients. Most don't.
From an API provider's perspective your app is simply an app using the APIs. Usually there is no such thing as a "staging" API, which does not deal with live production data. Whatever it is you are testing, you are testing it on live data right?
If you are able to register several different applications with for example different callbacks then I think your problem is pretty much solved. My view is that it should be the consumer's responsibility to keep these things separated.
I'm building some applications using rails.
All apps using restful auth plugin for User base and declarative authorization plugin for authorization rules.
But I need to merge all site's User accounts to one User base for providing login for all sites.
I.e like 37signals working on. Here is their work ;
http://37signals.com/accounts
How can I archieve this, any suggestions are welcome.
Thanks
A.Karr
From studying how 37signals was doing stuff - I think they're using RubyCAS http://github.com/gunark/rubycas-server
It's perfect for single sign-on, single sign-off and other related stuff - when you have multiple independent applications. Also, because CAS is a generic protocol, it exists for non-ruby/rails applications too. SO you can integrate legacy systems or client applications in Java etc.
I started building a set of how-tos on the subject here:
http://rubyglasses.blogspot.com/2009/12/rails-single-sign-on-with-rubycas.html
Have you thought about using open id?
If all your apps run on the same domain you shouldn't have any problems accessing the authentication cookie in all the apps, but you'll need to store the authentication state somewhere where all the applications can access it.