I am building a microservice project in which I need certain clarification on what to do in these situations:
for centralized authentication and authorization or centralized authentication on API gateway, every request must contain jwt token and pass-through API gateway to call other microservice also it should check which user has permission to access API in other microservice. So how can I handle those situations?
I will be using specific tool for exploitation.
users will come through either web browser or mobile app. your api gateway will be exposed to external world. most of the apiGateway nowdays contains plugins for authentication and authorization. for example you can use OIDC plugin with api gatway to authenticate the users which will return JWT token to call the internal apis. you can refer below component diagram link for architecture diagram
Related
I have an application set up as follows:
Angular UI -> Spring Cloud Gateway -> Spring Boot-based Service
I am attempting to authenticate my application against a limited Oauth SSO server with ONLY the following endpoints:
/authorize
/token
/userdata
The SSO does not provide an /introspect endpoint, nor does it issue JWTs.
What I would like to do is have Spring Cloud Gateway handle the authentication, but based on the result from /userdata, I would like to generate my own JWT to relay to the service.
My questions:
Is this possible?
If so, can someone give pointers or guide me to the resources that will get me started?
Spring Security OAuth2.0 Client and Spring Cloud Gateway combination works well in this case.
Client(Angular UI) requests to the Gateway service with OAuth2.0 login URL
The Gateway redirects the request to Identity Provider(Such as Google) login page.
After user login successful Identity Provider redirects the request to the Gateway with user info.
On Authentication success handler(Gateway service)
Parse user info and save it to somewhere
Create access token and refresh tokens. Set them to request cookies
Redirect to client(Angular UI)
I don't know the reason to pass the token downstream services at this point. If there is no specific requirement then I would implement all the security related operations on the Gateway service. Such as token generation, validation etc. This way new services can be easily added without concerning about authentication and authorization.
Here is a sample project.
I have API which is hosted in Azure. It is using Microsoft Identity platform for Authorization. Now we need to integrate APIM Gateway for the API. APIM also provides OAuth Authorization. So my question is should I configure OAuth for my API in APIM since Api would be deployed in APIM or I can continue to use Microsoft Identity platform which is doing its job. So I am looking for benefits for using OAuth from APIM rather than throw Microsoft Identity. In other words what would be difference and pros using OAuth vs Microsoft identity which also relies on OAuth?
Each API should validate a JWT access token on every request, then use the token's scopes and claims to authorize access to resources. This is sometimes called a zero trust architecture.
Another important requirement is to avoid revealing sensitive data in tokens, such as emails, to internet clients. The phantom token pattern has more info on this, and involves the use of an API gateway.
I would favour a solution where there is an API gateway in front of your APIs. This is a hosting best practice and also enables you to perform tasks such as cookie and token translation in the gateway.
APIM is one solution so I would favour that type of option if it improves your API security. There are other Azure options though, so it can be worth clarifying the types of things you want to do in gateways before choosing one. The API Gateway Guides may give you some ideas.
I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
Our apis are being consumed by 3rd party deamon applications as well as client applications. For third party deamon application we can expose the api via the client credential oauth flow and for the client application(S) we use the implicit grant outh flow.
The challenge we are facing is that in case of the implicit grant flow the user details are fetched from the ACCESS TOKEN. But when the same api is used for the client credential flow the user details can not be fetched from the ACCESS token as it has only application specific details.
What is the the best api design approach to handle the above challenge ?
Do I need two set of api(s) one for integrating with client application and one for integrating with server application ?
Will the usage of any alternative oauth flow help ?
Refer to Authentication scenarios for Azure AD documentation, as you stated correctly user interaction is not possible with a daemon application, which requires the application to have its own identity. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.
The quintessential OAuth2 authorization code grant is the authorization grant that uses two separate endpoints. The authorization endpoint is used for the user interaction phase, which results in an authorization code. The token endpoint is then used by the client for exchanging the code for an access token, and often a refresh token as well. Web applications are required to present their own application credentials to the token endpoint, so that the authorization server can authenticate the client.
Hence, the recommended way is two have two version of api implemented with two different type of authentication based on your scenario.
Reference -
Daemon or server application to web API
Understanding the OAuth2 implicit grant flow in Azure Active Directory (AD)
I have a project in which there are several microservices which are secured using spring oauth2.I have published these services on WSO2 API Manager and disabled the oauth2 feature of WSO2 as my services are already secured using spring oauth2.Now when I access my services published on WSO2, using token of spring oauth2 i get in response either status code 0 "no response" or status code 403 unauthorized.What could be the issue here.
The WSO2AM (API Manager) authorizes the clients using the OAuth protocol and the backend services should trust the WSO2AM providing service authorization.
The API MAnager is not able (by default) validate the tokens of your backend services.
As far I know WSO2 AM clears the "Authorization" header to the backend services. (correct me when I am wrong).
your options:
Setup a proper environment, where APIM is used to authorize users. The APIM can send a JWT token to the backend services with user identity and attributes and the backend service will validate and trust the APIM JWT token containing user identity and attributes. I really suggest you stick to the way how APIM works and not try to force it working other way
If you really must using your own OAuth tokens, you could send the authorization token in different header (which will not get cleared)
You could create a custom mediation flow to to re-enter the authorization header into the request (I am not sure if you will need to update the exposed api mediation flow too or not to skip the default authorizer).