I'm working upon a project which have multiple microservices for the restful APIs (Tech: NodeJS) which are running inside a single Docker container. So here I'm facing the issue to validate the AUTH Token. So can anyone help me to provide the best solution of this issue. A small guide will also be helpful.
Thank You,
I tried to check valid AUTH token inside each and every microservice. Which is not looking a good idea.
Related
I created a Rails API application, that is currently do his job awesomely, but I realized that is missing the most important part, a login from the React application and at the same time the authentication from a python application I developed that should consume those API as well.
Now, looking at the various offering, seems all fuzzy, at least from my prospective and I would like to have an advice that is not from 2016 or before but that is actual today.
Many solutions on the net, was getting dirty the main ApplicationController, that didn't make sense to me.
So I thought that a 'modern' way or let's say, 'a way' is to use doorkeep and devise.
I thought about Doorkeep because allow me to have the 'Applications' therefore I can delegate to applications the authentication in the proper way while using the JWT for the SPA application, but honestly I don't know from where to start deciding :)
I wanted to share here also the link of a blog post that inspired this question: https://www.vic-l.com/jwt-with-refresh-token-using-devise-and-doorkeeper-without-authorization/
Sadly something I found still, without an answer, at the moment, is Setting up DoorKeeper with multiple Rails/React applications?
Now, I can use doorkeeper to manage the JWT for the SPA and the applications for the client in Python ?
Thanks in advance!
Preface: I created the following issue in GitHub of the plugin and Alvaro Sanchez, the author of the plugin, recommended me to ask here which is the dedicated discussion channel for it.
We are migrating our Grails-based application to Kubernetes to allow multiple instances running simultaneously. The inherent problem is that the application will ask users to re-login if the request is served by the other pod that is not the previously same pod. We want to replace session-based authentication with token-based authentication.
I have come across writing on medium explaining how to use this plugin come long the source code published on GitHub, however, this tutorial didn't show how to customise the form-based login or something along those lines.
The key point here is to verify the existence of the defined token in order to redirect the login URL. However, I don't actually understand how and where we could intervene LoginController spring security core to check both username and token.
Apart from that, I cannot find any tutorials as well as documentation relevant to our need, so then I have raised this problem which someone experienced users can share their solutions.
If you have any idea, helpful tutorials or source code, could you please share with us?
Thank you in advance!
I'm building a small microservice-based webapp using JHipster with JWT authorization. The Architecture is simple, one gateway and two services with repositories. The problem that I had for the last few hours is the communication between the two backend-services.
At first, I tried to find a token on the services themself, but couldn't find it. If I just missed it in all the docs (quite overwhelming when beginning with the full stack :P), I would be happy to revert my changes and use the predefined token.
My second approach was that each service will authorize itself with the gateway at PostConstruct and save the token in memory to use it each API call. It works without a problem, but I find it hard to believe that this functionality is not already programmed in JHipster.
So my question is whether my approach is usual? If neither is true and there are some best-practices for it, I'm also interested in them.
It depends on the use case.
For user requests, a common approach is: the calling service forwards the token it received to the other service without going through the gateway suing #AuthorizedFeignClient.
For background tasks like scheduled jobs, your approach can be applied or you could also issue long life tokens as long as they have limited permissions through roles. This way you don't have to go through gateway.
Keycloak's offline tokens approach could also inspire you.
I'm trying to implement an OAuth2 provider for my web service.
It seems easier to implement the Authentication Server together with the Resource Server. The specification doesn't say anything about the communication between them.
Does anybody see a reason not to do this?
I had a post yesterday regarding this issue. I hope we can mutual answer each other. First to directly answer your question, I think it depends very much on the load that your app has to handle. If you have to scale your app to many resource servers, keeping a separate auth server is the best because you can centrally manage user credentials and access_token in one place.
Here is my question. I believe if you have tried something similar to mine, you can give me some suggestions.
OAuth - Separating Auth Server and Resource server returns invalid token when accessing protected resource
We are running two restful apis, one with http and the other is with udp.
They are running on premise infrastructure and within next few release, we'd need run them as google container once we dockenize them
Before we put the service up in cloud and all that, we need to implement oauth!
My question is that where to start and how we should approach implementing oauth 2 considering the road map I described?
Truly appreciate any suggestions.
It kind of depends on what you want to use OAuth2 for.
One option is toThere are OAuth2 implementations for most languages (e.g. https://cwiki.apache.org/confluence/display/OLTU/Index)
This allows you to keep your own login/password system.
If you'd rather delegate the auth and identity to a provider like Google, then you just need to implement the OAuth2 dance to get a user's identity from Google, see https://developers.google.com/accounts/docs/OpenIDConnect for more details.
(and when it comes time to use container engine, visit us on IRC #google-containers if you have questions about containers and Google!)