We are building a suite of spring boot based microservices deployed in Kubernetes. APIs are authenticated using OIDC protocol and access to APIs is managed through Kong community edition.
There have been suggestion to centralize authentication at API Gateway level. I am all for centralizing the authentication, but I am not able to identify if it really helps simplify the APIs. Authentication is already externalized and APIs still have to validate the JWT token with OIDC provider.
Are there any other benefits of centralized authentication at API Gateway ?
You can delegate the JWT validation to the API Gateway through techniques like introspection. This way your APIs don't have to deal with authn/authz at all. You can also plug new service APIs with ease.
Related
A quick thanks and appreciation for your help. The main gist is I am creating a microservice ecosystem and will be using Istio as my service mesh. For the services themselves, I am using Spring Boot. For auth I am using a JWT implementation.
Spring security is the staple for route protection and auth. However, Istio can use its sidecar to deny any request to the service API if the JWT validation fails.
Is there any value to including spring security as an authentication filter if the JWT has already been validated? The services will conduct their business logic based on the info taken from the validated JWT.
Thanks!
I have implemented microservices architecture in Spring Boot. All services are accessible from the front-end. There are 2 types of API in few Microservices -
Public - (Directly Accessible from the front-end)
Internal - (for inter-service communication)
I have implemented JWT based authentication. But I want to know how to implement auth for internal APIs?
In internal API we will not get the JWT token. Auth is needed because someone can mock a private API.
For Authentication, we are using an auth service. All other services call the Auth service before every API call to authenticate the request.
Auth is needed because someone can mock a private API
While this may be true, an attacker would need to be inside your network already.
However, assuming you still need secure intra-service communication, you could look at service discovery to mediate this communication. Service registry platforms such as Eureka or Consul, will allow you to set up service discovery.
Eureka is commonly used in sprint boot applications, and is fairly lightweight, but weighted toward AWS hosting.
In addition to other benefits, such as configuration management, failure detection, and load balancing, these platforms will also enable you to secure your intra-service communication.
I have been exploring APIgee and okta configuration using https://github.com/tom-smith-okta/okta-api-center repo. Here APIgee edge acts as a gateway to https://okta-solar-system.herokuapp.com/ api’s and the token for authentication is generated via okta. My understanding is that https://okta-solar-system.herokuapp.com/ doesnt have any okta authentication enforcement. The check is via apigee.
If I were to replace https://okta-solar-system.herokuapp.com/ with a spring boot application hosted publicly should the application have okta security enabled (eg : https://github.com/oktadeveloper/okta-spring-boot-oauth-example) or should i follow same procedure as above and delegate enforcement of token to apigee, without any security enforcement on the spring boot application?
Can someone tell me what is the standard way of implementation I should follow?
If the spring boot application has no enforcement of security, what is to prevent someone from bypassing the Apigee API gateway and calling it directly?
If you have successfully managed to secure the spring boot application so that only the API gateway can communicate with it (via mutual TLS connection, IP allow listing, etc), you might be able to forego any enforement at the service level, but I would recommend doing some authorization checks in the service itself.
All of my Micro Services, checking client access token validation using Rest API call to against my Authorization micro service which make a coupling between all the services to the Authorization Micro Service. The problem is that the token located only on the Authorization service Database. Is there a better way to do it instead of rest api?
Usually i prefer amqp over Rest API to avoid coupling but i can't see other option. Could someone help with that?
I'm trying to implement Google's Streamlined Identity Flows for authenticating users on Actioins on Google with Spring Boot and Spring Security (OAuth).
I already managed to implement Google-SignIn but the server side is missing. I could implement every endpoint myself but as with most security concerns I think that it's better to use tested and proved frameworks or components. Now I'm trying to figure out how to use Spring Security's OAuth authorization server functionality.
How to implement the authorization endpoint that lets users authenticate with their browser and respond an authentication token
How to implement the JWT token endpoint
Is it possible to leverage the possibilities of Spring OAuth for this or do I have to create a custom endpoint with #Controller / #RestController for example.
Are their any tutorials or documentations on how to implement such a service with Spring Security?