Microservices API Architeture Question

[Alexandre Arcanjo de Queiroz]

Hi. I have a system built using this architecture: A front-end web application with spring security and some REST microservices developed with some different technologies like Java (Spring Boot), GoLang, Python (Flask) and Ruby (Sinatra). 

My question is: What is the best alternative to secure these microservices considering ajax front-end calls from front-end web application and server-side calls between microservices? OAuth 2.0? I know that OAuth 2.0 seems more like a delegation than authorization or authentication protocol/technology.

Greetings.

Alexandre

[Michael Tiller]

I have not actually done any serious production stuff in this area.  So, in a sense, I have the same question as you.  But one of the things I had been thinking about using here were JWTs.  My thinking was that you could have some central services that authenticates you in some way and then issues you a JWT which then provides information about what you are authorized for.

Each service could then take the JWT and open it up to see if what you are asking for is authorized based on the JWT payload.

An analogous approach (which is slightly more centralized) would be to use nonces instead of JWTs and then have an additional service that allows you to query for authorization information for individual services.  This would avoid the problem of having too much information wrapped up in the JWT and also some of the potential security concerns arounds JWTs if you lost control of the key.

But I want to stress I haven't really done any of this in production.  So I'm mainly throwing these comments out here not as suggestions to you, but to get feedback on the downsides of those approaches from others in this group.

--

Mike

ᐧ

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Jørn Wildt]

I would like to add to Michael's response that you should look into OpenID Connect which uses JWT for "Identity tokens" - a formalized secure standard way of transfering user identitiy information.

I found this explanation that covers it: http://nordicapis.com/how-to-control-user-identity-within-microservices/

/Jørn

[Andrew B]

This is a big question! But one thing worth considering is that securing ajax calls is quite a different beast from securing server-side API calls.

Ajax calls come from the browser, which must be considered to be in enemy hands. So you shouldn't ever hold any secret keys in the browser, which means the browser will need to cooperate with a server to obtain tokens. Also, if you want to support a browser making ajax calls to some web site other than the one that served up the page the Javascript lives within, you need to use CORS which adds a wee bit of complexity/funkiness.

 

Many people work around this by using a pattern where all ajax calls are not really secured by token but instead go straight back to the web site that served the page - and from there, the web site proxies them off to the actual destination server.

To put it another way, the ajax request is not secured via token at all (as a server request would be), but instead by cookie as a web page would be.

You can see this in action in Grafana for example. Grafana is a cool graphing tool built as a single page application. To populate the graphs, the Grafana javascript needs to perform queries against a database. To avoid auth problems, instead of the web page somehow doing this directly, it instead makes the calls to a proxy API http://docs.grafana.org/reference/http_api/#data-source-proxy-calls on the grafana back end.

Back on the grafana server, this proxy API call is then shovelled straight on to the database without any actual processing. I'm not really sure how they've implemented it, but using nginx or such this could probably even be done without any need to buffer the request and response anywhere in the server code.

So tl;dr:

One thing you might consider is not to struggle with token (e.g. OAuth) based auth at all for your ajax calls - instead require them to be same origin and use the same auth you would use for secure web pages, i.e. cookies.   

Then your server side auth can be more traditional stuff, i.e. OAuth, maybe using JWTs as tokens as discussed, etc.

[Andrew B]

Damn. Update to the above - grafana actually does use tokens rather than cookies for its ajax calls. So not a good example! Sorry.

But the idea is still the same -  if it works for your application, then you may find it easier to secure your ajax calls in the same way as your web traffic, rather than dealing with tokens in the client.

[Lukas Rosenstock]

Hello Alexandre,

the security concerns are different between client-to-server calls and microservice-calls. First of all it’s important to know more about your infrastructure. Do the calls from the client go to only one service or multiple? If multiple it’s best to rethink this architecture or include a proxy layer to handle authentication and proxy calls. If calls only come from a web-based client it’s easiest to just go with regular session cookies.

For the calls between microservices it depends how trusted the environment is. If you have a locked down architecture where the services cannot be called from the public Internet there’s not too much to worry about in terms of security and you can use whatever works easiest for you in all languages that are used. It all depends on which information about users and sessions the respective backend services need.

Hope I could help a bit.

Regards,

Lukas Rosenstock

https://cloudobjects.io/

--
You received this message because you are subscribed to the Google Groups "API Craft" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.

[Daniel Torok]

Hi,

sorry for joining the conversation late.

In our environment a service treats the other services with the same lack of trust as it treats the browsers. I I think it's not only a hacker attack that we have to fear but also potential software bugs that may cause damage in any database.

Our browsers use the APIs with their JWT-like cookies, while services use basic auth for authentication. In order to have better authorization we started to use the oauth2 concept inside, and with every s2s request we pass the user's context too (the original cookie), so the same permission checks can be made on the API side regardless of the sender of the request (i.e. browser or an other service).

This method simplified a lot of things for us, especially that the service can have only one API used for c2s and s2s communication.

If you are interested in the details, I actually talked about that on muCon conference in London last year: https://skillsmatter.com/skillscasts/8742-user-and-inter-service-authentication-at-prezi

I hope this helps,

Dani

-- 

Daniel Torok
Senior developer at Prezi
Budapest, Hungary

Lukas Rosenstock

https://cloudobjects.io/

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.

[nik]

Oauth 2.0 will multiple grant types be the best option in my opinion. 

But need to keep in mind if there is any requirement of passing metadata along with oauth access token then JWT will be better option.

Thanks

Nik

[Soheila Dehghanzadeh]

Hi Andrew, All,

In the example provided by Jorn (http://nordicapis.com/how-to-control-user-identity-within-microservices/), the mobile app is actually performing ajax calls to the mail server but it is still said to use oauth for it (that's actually why token is a hash and doesn't expose user data). My question is does the server-side API calls perform the same procedure?

any comment is highly appreciated.

Thanks.

Soheila