I want to implement login and logout functionality and retrive user details like username and user role using Azure Active Directory.
We are using Docker to deploy Spring cloud microservices project on Azure cloud. Could you please suggest me steps to get user details?
Do we need to secure all microservices edge points using Spring cloud OAuth2 security using JWT or just we can secure one web microservice ? Do I need any permission ,specific user roles to implement this?
You can find Azure's documentation about OAuth 2.0 support for AAD here
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-protocols-oauth-code
I've got an application that's using OAuth 2.0 with a different Authentication Server, and I'm about to see if I can use AAD as the Authentication Server. But, whatever ends up being your Auth Server, the rest of the application should be the same...
The Auth Server handles the log in (typically as a Single-Sign On pattern)
The Auth Server will return a Json Web Token (at some point, depending on the Grant Type being used to retrieve it)
The JWT should be included in each subsequent request to ensure the caller has authorization
From a Spring perspective, you'll need at least a SSO Client (denoted by the #EnableOAuthSSO annotation). If everything in hosted by that process, you'll need that JWT to call subsequent methods. If you have processes hosted in other processes, it's likely you'll want them secured as well. Using the #EnableResourceServer annotation will configure Spring Security to look for the JWT, just not attempt to retrieve one if the request does not have it.
Unless the endpoint is meant to be publicly accessible, you will want to secure it. Of course, I really don't know the context of your application, so this statement is purely an uninformed opinion based on zero knowledge of what you're trying to do with your application. Take it for what it's worth.
EDIT
This has become a little more complex than I originally thought. I have been able to write some code to dynamically retrieve the public key from Microsoft in order to validate the returned JWT.
But, the main issue is the fact the Azure AD supports Open Id Connect when acting as an Identity/Authentication Server. And, at the moment, spring-security-oauth2 doesn't support Open Id Connect.
I was able to make some small changes to the spring code, but I did ask the question to the Spring group and they are actively working on adding support for Open Id Connect. They hope to have a release two months (ish?).
For the short term, the oauth2 support doesn't support Open Id Connect. Given this is the protocol used by AAD, the current version of oauth2 won't work with AAD. That said, I will be happy to wait for the official support which shouldn't be too long.
Related
So my project has got a two asp.net projects. One is for showing date(User Interface) and the another one is API(for background processes like login, database calls and etc.). Right now my app has Username and Password feature to login. I have setup a startup class in my API which authenticates the user and pass the user token. Now I want to add a feature to login through Azure portal.
Can anyone suggest me a good practice in this situation? Like I don't want to change my code and just add a feature. Should I make changes in API or Web or Both? Meanwhile I was reading about expose api in app registration. Will it be appropriate to use it just for login purposes?
Azure AD supports OAuth2, OIDC and SAML. See more information here. It is probably best to introduce the mechanism through the API first, since it would apply to the frontend as well (though slight modifications may be required there as well).
I am going to build a web application that allows users to sign in with their Google or Twitter account. I think OpenID Connect(OAuth2) is the standard today to verify the identity.
I also want to provide several API services that can be only accessed with a valid access token from either Google or Twitter.
For example, all the four API's above are going to be public and so I have to protect from unauthorized users. For NodeJS based API services I can use http://www.passportjs.org/ to protect all APIs.
Assume, in the future the number of API's will be grow for example up to 20 API's and sign in with Facebook account will be also allowed.
Again, all the API's have to be protected and I have to do it 16 times with http://www.passportjs.org/.
In addition add the new provider Facebook, I have to do the changes on all 20 APIs.
The question is, is their a way to keep centralized, which means in the future when I will provide more the providers for example GITHUB for sign in I would like to do changes in one place not in 20 places.
Is the tool https://www.ory.sh/hydra what I need?
These are perhaps the two primary features of OAuth 2.0 and Open ID Connect:
Federated sign in to your UIs via multiple identity providers and the ability to easily add new options such as GitHub in a centralised manner
Full control over claims included in access tokens, so that your APIs can authorize requests however you'd like
FOREIGN ACCESS TOKENS
You should aim to avoid ever using these in your apps. Your UIs and APIs should only use tokens issued by your own Authorization Server (Ory Hydra), which manages the connection to the Identity Provider. Adding a new sign in method will then just involve centralised configuration changes, with zero code changes in either UIs or APIs.
IF YOU DON'T HAVE AN AUTHORIZATION SERVER YET
Maybe have a look at the Curity Identity Server and its free community edition - use sign in with GitHub, which has strong support for both of these areas:
Many Authenticators
Many Options for Issuing Claims
EXTERNAL RESOURCES
One exception to the above is that your APIs may occasionally need to access a user's Google resources after login, by calling Google APIs. This would require the token issued by Google. It can be managed via an embedded token approach - though it doesn't sounds like you need that right now.
I have an OpenID Connect provider built with IdentityServer4 and ASP.NET Identity, running on let's say: login.example.com.
I have a SPA application running on let's say spa.example.com, that already uses my OpenID Connect provider to authenticate users through login.example.com and authorize them to access the SPA.
I have a mobile app (native on both platforms) that is using a custom authentication system at the moment.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
So I started by looking on the OpenID connect website and also re-reading the RFC6749, after a few google searches I realized that was a common problem and I found RFC8252 (OAuth2 for Native clients), also Client Dynamic Registration (RFC7591) and PKCE (RFC7636).
I scratched my head about the fact that it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised.
I disscussed the topic with some co-workers and we came out with the following set-up:
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Use an AuthenticationCode flow for both clients and enforce them to use PKCE.
Use a redirect_uri on the app associated domain say: https://app.example.com/openid
Make the user always consent to log-in into the application after log-in, because neither iOS or Android would bring back the application by doing an automatic redirect, it has to be the user who manually clicks the universal/app link every time.
I used AppAuth library on both apps and everything is working just fine right now on test, but I'm wondering:
Do you think this is a secure way to prevent that anyone with the right skills could impersonate my apps or by any other means get unauthorized access to my APIs? What is the current best practice on achieving this?
Is there any way to avoid having the user to always "consent" (having them to actually tap the universal/app link).
I also noted that Facebook uses their application as a kind of authorization server itself, so when I tap "sing-in with facebook" on an application I get to a facebook page that asks me if I would like to" launch the application to perform log-in". I would like to know how can I achieve something like this, to allow my users login to the SPA on a phone by using my application if installed, as facebook does with theirs.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
This is what OAuth 2.0 and OpenID Connect provides you. The ability to use single user identity among different services. So this is the correct approach .!
it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised
Correct. From OAuth 2.0 specification perspective, these are called public clients. They are not recommended to have client secrets associated to them. Instead, authorization code, application ID and Redirect URL is used to validate token request in identity provider. This makes authorization code a valuable secret.!
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Not a mobile expert. But yes, custom URL domains are the way to handle redirect for OAuth and OpenID Connect.
Also usage of PKCE is the correct approach. Hence redirect occur in the browser (user agent) there can be malicious parties which can obtain the authorization code. PKCE avoid this by introducing a secret that will not get exposed to user agent (browser). Secret is only used in token request (direct HTTP communication) thus is secure.
Q1
Using authorization code flow with PKCE is a standard best practice recommended by OAuth specifications. This is valid for OpenID Connect as well (hence it's built on OAuth 2.0)
One thing to note is that, if you believe PKCE secret can be exploited, then it literally means device is compromised. Think about extracting secret from OS memory. that means system is compromised (virus/ keylogger or what ever we call them). In such case end user and your application has more things to be worried about.
Also, I believe this is for a business application. If that's the case your clients will definitely have security best practice guide for their devices. For example installation of virus guards and restrictions of application installation. To prevent attacks mentioned above, we will have to rely on such security establishments. OAuth 2.0 alone is not secure .! Thats's why there are best practice guides(RFC68129) and policies.
Q2
Not clear on this. Consent page is presented from Identity Provider. So it will be a configuration of that system.
Q3
Well, Identity Provider can maintain a SSO session in the browser. Login page is present on that browser. So most of the time, if app uses the same browser, users should be able to use SPA without a login.
The threat here comes from someone actually installing a malicious app on their device that could indeed impersonate your app. PKCE prevents another app from intercepting legitimate sign in requests initiated from your app so the standard approach is about as safe as you can make it. Forcing the user to sign in/consent every time should help a bit to make them take note of what is going on.
From a UX PoV I think it makes a lot of sense to minimize the occasions when the browser-based sign in flow is used. I'd leverage the security features of the platform (e.g. secure enclave on iOS) and keep a refresh token in there once the user has signed in interactively and then they can sign in using their PIN, finger print or face etc.
I developed my Heroku app that exposes APIs only (no UI) and it works fine.
But how can I restrict the APIs to certain authorized/authenticated users only?
I absolutely need an authentication layer to protect the app APIs and prevent unauthorized accesses. A sort of login(user, psw) call to use before an external system can start invoking my API.
But I don't find any reference in the docs, it only says that these are the main security best practices:
Heroku SSL
Force the use of HTTPS
Trusted IP Range
Any idea?
That's something you'll need to implement at the application layer and not something that Heroku provides. At it's simplest you could implement basic auth in your app so that the user would pass them with their request, a more complex solution would involve user accounts and oauth etc etc.
You could implement all the authentication logic directly in your app.
Alternatively, take a look Auth0, which basically provides you with authentication and identity management as a service. You can easily add Auth0 to your Heroku app as a free add-on via the Heroku Elements marketplace.
They have lots of different use-cases and associated walk-throughs, and they offer a very generous free-tier.
From your requirements, it sounds like you might want to look at Auth0 Machine to Machine applications, using the OAuth2 Client Credentials Grant. With that, your external system(s) would basically need to authenticate with Auth0 using a Client Id and Client Secret (that you could generate in Auth0 and supply to them). Then, they would access your API with a JWT that you could easily validate in your app (Auth0 will provide you with generated code in many different languages for you to do that very easily). Your API will then reject requests without a valid JWT (by sending a "401 Unauthorized" response).
This may all sound a little intimidating at first, but it's really worth going through the relevant Auth0 "quickstart". They really go out of their way to try to make it as easy as possible!
I'm trying to design a green-field project that will have several services (serving data) and web-applications (serving HTML). I've read about microservices and they look like good fit.
The problem I still have is how to implement SSO. I want the user to authenticate once and have access to all the different services and applications.
I can think of several approaches:
Add Identity service and application. Any service that has protected resources will talk to the Identity service to make sure the credentials it has are valid. If they are not it will redirect the user for authentication.
Use a web-standard such as OpenID and have each service handle it own identities. This means the user will have to authorize individually each service/application but after that it will be SSO.
I'll be happy to hear other ideas. If a specific PaaS (such as Heroku) has a proprietary solution that would also be acceptable.
While implementing a microservice architecture at my previous job we decided the best approach was in alignment with #1, Add identity service and authorize service access through it. In our case this was done with tokens. If a request came with an authorization token then we could verify that token with the identity service if it was the first call in the user's session with the service. Once the token had been validated then it was saved in the session so subsequent calls in the user's session did not have to make the additional call. You can also create a scheduled job if tokens need to be refreshed in that session.
In this situation we were authenticating with an OAuth 2.0 endpoint and the token was added to the HTTP header for calls to our domain. All of the services were routed from that domain so we could get the token from the HTTP header. Since we were all part of the same application ecosystem, the initial OAuth 2.0 authorization would list the application services that the user would be giving permission to for their account.
An addition to this approach was that the identity service would provide the proxy client library which would be added to the HTTP request filter chain and handle the authorization process to the service. The service would be configured to consume the proxy client library from the identity service. Since we were using Dropwizard this proxy would become a Dropwizard Module bootstrapping the filter into the running service process. This allowed for updates to the identity service that also had a complimentary client side update to be easily consumed by dependent services as long as the interface did not change significantly.
Our deployment architecture was spread across AWS Virtual Private Cloud (VPC) and our own company's data centers. The OAuth 2.0 authentication service was located in the company's data center while all of our application services were deployed to AWS VPC.
I hope the approach we took is helpful to your decision. Let me know if you have any other questions.
Chris Sterling explained standard authentication practice above and it makes absolute sense. I just want to put another thought here for some practical reasons.
We implemented authentication services and multiple other micro services relying on auth server in order to authorize resources. At some point we ran in to performance issues due to too many round trips to authentication server, we also had scalability issues for auth server as number of micro services increased. We changed the architecture little bit to avoid too many round trips.
Auth server will be contacted only once with credentials and it will generate the token based on a private key. Corresponding public key will be installed in each client (micro service server) which will be able to validate the authentication key with out contacting auth server. Key contain time generated and a client utility installed in micro service will validity as well. Even though it was not standard implementation we have pretty good success with this model especially when all the micro services are internally hosted.