We currently use WSO2 Api Manager to reach some backends.
The thing is, the consumer must :
First authenticate to the API Manager (Oauth)
Then authenticate to the Backend api (Whatever security in place, as options provided by API Manager to handle it itself is quite poor)
Make the call
I find it heavy :
Many calls just to do one real call.
Loose the "loose coupling" advantage API Managers should provide
Do you think we are doing right ? Shouldn't Api Managers deal with backend authentication ?
Thanks in advance for your help !
This depends on how you want to do this. It is not mandatory to have Oauth2 protection and backend authentication. This can be done in the following ways.
If you want only to allow backend authentication
Then you can set the Authentication type to None. Then Oauth2 won't apply. - https://wso2.com/blogs/cloud/oauth-and-authentication-type-application-vs-application-user/
You can allow Oauth2 only
If your backend is insecure and needs a way to expose, this is the best option.
If you need both authentications
There can be some cases that your backend is used by some other parties and there is no option to remove backend authentication. Also, you need the Oauth2 protection for the API and make it secure in API gateway level. Then this is the option.
Hope this is clear. WSO2 has these capabilities and you can chose any option.
Related
I am thinking about how I will implement authentication in my react application and even after hours of reading I still have few questions. Please provide any information you think could benefit me I would like to really understand the problem it could be that my line of reasoning somewhere implies I don't fully understand something I would appreciate if you could point out where I am wrong.
Infrastructure:
SSR React app served behind reverse proxy on <domain_name>
.NET 5.0 api server using asp.net identity served behind reverse proxy on api.<domain_name>
Reverse proxy provides SSL so https:// on both
General information:
I need to support external logins (Google, Facebook etc)
Paying for Auth0, Okta etc is not an option
No 3rd party apps are going to authenticate against me
Client is web browser
I don't need to support outdated browsers
Questions:
Do I need IdentityServer4 at all? I am never going to act as an authentication authority for 3rd party apps.
I can still support external logins without using IS4 right? I just need to handle redirect callback I can see there are methods such as GetExternalLoginInfoAsync, ExternalLoginSignInAsync which should make the job easier.
The reason why every SPA authentication tutorial recommends Auth Code + PKCE is because they assume you want to be authentication authority, don't have API on the same domain, or were written before SameSite cookies existed?
My plan is to write a custom login route assigning SameSite cookie and that's it. This makes client-side code super simple no shenanigans with adding access tokens to headers before making calls.
Is it possible? I found few articles describing something very similar but I am not sure.
With a setup like that is there something that is just not going to be possible? Like remote logout, banning users, or whatever you can think of.
You don't have to implement IS4 if you don't want to (especially since IS4 will have its support shut down in November 2022). You can just read the OAUTH2 documentation and implement the routes you need and still be OAUTH2 compliant.
You will have only one client (your react app) so no dynamic client registration, just the 2 following routes:
the authorization endpoint to get an authorization code when the user successfully authenticated himself using an external provider. This authorization code has to be used ONLY ONCE in the next route.
the token endpoint to get an access token and a refresh token using the authorization code given above or a refresh token given before. If the same authorization code or refresh token is used twice, you have to revoke the tokens given in the first call because this should not happen.
With a setup like that is there something that is just not going to be possible? Like remote logout, banning users, or whatever you can think of.
Besides these 2 routes you are free to implement whatever you want. Like a route to allow user to revoke all of his sessions.
To answer more precisely to your questions:
Do I need IdentityServer4 at all? I am never going to act as an authentication authority for 3rd party apps.
No you don't need it if you don't know exactly why you need it. It does not have anything to do with the fact that you are not going to act as an authentication authority for others clients.
I can still support external logins without using IS4 right? I just need to handle redirect callback I can see there are methods such as GetExternalLoginInfoAsync, ExternalLoginSignInAsync which should make the job easier.
Yes you can, as long as you store the authorization code and the refresh token when the user successfully signed in using the external provider.
The reason why every SPA authentication tutorial recommends Auth Code + PKCE is because they assume you want to be authentication authority, don't have API on the same domain, or were written before SameSite cookies existed?
I would assume that they are oriented Oauth2 compliance. But if you don't need nor want to implement OAuth2 framework, then don't. But in my opinion you should, it is really easy to implement.
Migrating an SPA web app (Angular) and ASP Core Web API from Auth0 auth provider to Identity framework due to some requirements and limitations.
Until now everything was handled by auth0 and I didn't give it a much thought about the whole process of authentication. I would simply redirect users to auth0 hosted login page where it'd handle everything, callback with access token and I would use it for calls to API where API would just verify the JWT.
Now that I need to do this all manually, I am a bit confused. I want to have multiple authentication options: either Email/Password or OIDC auth providers like Google/Github.
I can get access token from these OIDC providers without much problem. But what do I do exactly with it, or to be more precise how do I configure Identity framework to handle the rest, without doing a lot of manual work? All users have quite a bit of additional data inside Identity framework user classes and I'm not fully sure how do i connect that to OIDC tokens.
Sorry for a bit abstract question, I think I'm missing some small detail, but at the moment I'm just really confused.
A lot of this is in place already, so to test the OIDC tokens, you just need them to be accepted by your consuming API.
To do so, you need to do some configuring, probably the same as you did for Auth0. Since the dependency here of the external providers, I'll post a link:
MSDN Google Auth
To accept them, you'll need the following steps:
register your API with the exteral provider
use the, provider dependent, instructions to set it up in your API.
The providers are additional to the one you have in placed and are referenced by Identity as ExternalProviders
In general, it's pretty easy. Possible some things are left out, since I don't know your exact use case.
So you are using an Identity Provider, previously Auth0, and now another (or custom) one.
Just for sanity a recap of your use case:
You trust the Identity Provider so every token signed by this provider is valid.
Your Identity Provider (and the external ones e.g; Facebook, Google etc) are responsible for their own user management.
Your own Identity Provider needs to handle specific authentication methods, tested against a corporate UserStore. These need to be managed, possibly with AD, Identity username/password or something similar.
Your Identity Provider provides authentication through JWTs
You also want to use external Identity Providers like Facebook etc.
So, as for the setup, you must do the following:
Implement (or reuse, or use ActiveDirectory or any other) user management tools, if you need to perform some management on them. This means password recovery and all that stuff, which is available in a lot of standard libraries (I think it comes out of the box in Identity)
Define clients, scopes and claims throughout your system(s). Possibly there is some effort to be made.
Make sure the JWT's are accepted as authentication throughout your system (this was already in place) and the proper claims are assigned when called for the correct client.
Register your API with the external providers
Setup your API to accept the external JWT tokens (needs some setup with secrets and API keys)
A lot of this is already in place in the Identity framework. There is an article about it here.
If you are willing to do a good exercise (and a lot of work), you could also try to implement things fully customized with IdentityServer4
I am searching a way to use Basic Authentication on the API I expose through WSO2 API Manager.
As I could see by default it uses OAuth, and I didn't find a way to choose to use Basic Authentication instead.
Is it possible?
Thanks
There is no out of the box way to secure your APIs with basic authentication in WSO2 API Manager. But you can write a new authentication handler for your requirement.
However please note you need to evaluate the security mechanism and how it is applied via a handler first. For example, when the current handler receives an OAuth2 access token, it knows the user, application, subscription information. That's how it knows how to throttle and publish stats accordingly. You need to be able to find these information from your new handler you introduce for the throttling and stats to work accurately.
Reading this question, #Pinpoint's answer and the further discussion on comments, I'm well aware that natively we can't add an identity provider to our apps developed with ASP.NET 5. One possible replacement for the legacy OAuthAuthorizationServerMiddleware is then provided by the AspNet.Security.OpenIdConnect.Server as I've found in many places.
Now, there is one point that I'm still unsure about all this because I'm really not an expert in security, so my knowledge about OAuth is not very deep. My doubt is the following: is it possible to use an external identity provider when using OAuth to protect one RESTful API?
Notice that I'm not talking about adding social login to one website, I'm talking about using one external identity provider in one RESTful API.
My point is, this makes me a little confused yet, because I always thought this should be a concern of my app.
So my question here is: when using OAuth and ASP.NET 5, is it possible to use an external identity provider, other than implementing one? If it is possible, how this works in short? I mean, my app still needs to be able to manage the identities of users, in the sense that it needs to manage claims and so on.
In that case, if it is really possible, how the flow would be? The external identity provider should issue the tokens? But how my app would be able to verify those tokens and manage users identities?
EDIT: One of the reasons I feel unsure about that is that when we use the UseOAuthAuthentication extension method, we set up one callback path which is described as
The request path within the application's base path where the user-agent will be returned. The middleware will process this request when it arrives.
Now, if we are developing a site, then this really does make sense. The person goes there, click a button to login with a provider like Facebook. The user is redirected to Facebook's page and then after he logs in, he is redirected to some page of the site.
On the other hand, with a RESTful API this is meaningless. There is no notion of being redirected.
This makes it seems that the usage of external providers is only for sites and not for RESTful API's. This is the main point of my question.
My doubt is the following: is it possible to use an external identity provider when using OAuth to protect one RESTful API?
Yes, it's definitely possible. This is exactly what you do when you use Azure Active Directory to protect your API endpoints:
app.UseOAuthBearerAuthentication(options => {
options.AutomaticAuthenticate = true;
options.Authority = "https://login.windows.net/tushartest.onmicrosoft.com";
options.Audience = "https://TusharTest.onmicrosoft.com/TodoListService-ManualJwt";
});
The next legitimate question is: if you can use the tokens issued by AAD to protect your API, why couldn't you do the same thing with Facebook or Google tokens?
Unlike Facebook or Google, AAD issues completely standardized tokens named JWT tokens that the OAuth2 bearer middleware can "read" and "verify" to determine whether the token is still valid and was really issued for your API (i.e if the audience attached with the token corresponds to your API. You can control this value using the resource parameter when making your authorization request).
You can't do something similar with FB or Google tokens, since they are totally opaque. Actually, it's not really surprising since these tokens have only one objective: allowing you to query FB or Google APIs, not your own ones (these social providers don't allow to set the audience of the access token).
Since you can't read the token yourself, the only option is to ask FB or Google whether it is still valid to make sure your API doesn't accept invalid tokens. That's something you can (easily) do with Facebook as they offer a "token inspection endpoint" you can query for that: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow (see the Inspecting access tokens chapter). This way, you can ensure the token is not expired and determine the user corresponding to the token.
Sadly, this approach has two downsides:
You have to make an extra HTTP call to the Facebook endpoint to validate the access token, which implies caching received tokens to avoid flooding Facebook with too many requests.
As the access token is not issued for your own API, you MUST absolutely ensure that the access token was issued to a client application you fully trust, or it will allow any third party developer to use his own FB/Google tokens with your API without having to request user's consent. This is - obviously - a major security concern.
You can find more information in the last part of this SO answer (it's for Katana and about Dropbox, but you should get the idea): OWIN/OAuth2 3rd party login: Authentication from Client App, Authorization from Web API
So my question here is: when using OAuth and ASP.NET 5, is it possible to use an external identity provider, other than implementing one? If it is possible, how this works in short? I mean, my app still needs to be able to manage the identities of users, in the sense that it needs to manage claims and so on.
In that case, if it is really possible, how the flow would be? The external identity provider should issue the tokens? But how my app would be able to verify those tokens and manage users identities?
To work around the limitations mentioned in the previous part, the best option is - as you've already figured out - to create your own authorization/authentication server. This way, your API doesn't (directly) accept FB or Google tokens but the tokens issued by your own server, that can possibly redirect your users to FB or Google for authentication.
This is exactly what this sample does: https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/tree/vNext/samples/Mvc
The user is invited by the client application (Mvc.Client) to authenticate with your authorization server (Mvc.Server) so he can get an access token to later query the API (also in Mvc.Server). For that, the user is redirected to your authorization server, which itself offers you to authenticate with Google or Twitter.
When this external authentication step is done, the user is redirected back to your authorization server (Mvc.Server), where he's asked to give his consent for the client app (Mvc.Client) to access his personal data.
When the consent is given, the user is redirected back to the client application with the access token you can use to query the API endpoint.
I built a wcf rest service with form authentication. All the settings are set in config file. This service needs to be consumed by android client. So can any body please tell me how to send the request with log in credential to the rest service which is implemented using forms authentication.
Note: I know by implementing custom login service method we can validate the client and pass the cookie for the wcf rest method to authenticate.
I am looking for different solution like in single request we pass the credentials it validates the user with membership and gives the response. Please let us know if u need any further information.
This is a very broad question, so it will be difficult to answer completely. For the WCF side, you can follow this: How to Consume WCF Service with Android. The idea is to return a token, or session, ID when the user successfully authenticates in the system, and each subsequent request uses this token to identify itself. That approach uses SOAP, but you can also use REST too, which REST may be easier to consume in an Android client (REST worked great for me).
See this post, Need advice on authentication for android client connecting to the WCF Rest setup, for more guidance on the setup too. When I setup my authentication mechanism, I did a lot of research online to figure out the best approach to take. A lot of people mentioned just use OAuth 2, and make sure you are using HTTPS communication. So if you can use OAuth or Facebook/Twitter/Google+ for authenticating, that would be a good approach and take a lot of the headaches away.