fliprank: what is micro services authentication strategy in spring

micro services authentication strategy

All about building secure micro-services

Why need security in microservices?

Microservices talk to each-other. So all the communication links between micro services need to have a way to make security decisions whether or not they are allowed to communicate and if at all, what are the authorization levels.

What protocol does your microservice speak?

· HTTP (REST, SOAP)

· AMQP (Messaging)

· Apache Thrift (Remote Procedure Call Framework)

· gRPC (google’s RPC)

· custom TCP protocol and likewise…

What we just got to know is, it’s not just a HTTP protocol which is in picture, and therefore decision on making a choice on the security standard must take into account the protocol flexibility.

Solution:

Every request to a microservice must include a security token that the microservice can easily authenticate and use for making authorization decision.

Self-Learn : Look back on what is Authentication and Authorization???

Problems to solve

1 What format should security token use?
2 How are tokens supposed to be obtained?
3 What libraries should be used for authentication and authorization when implementing micro services?
4 What information should be in the token?

n Use a “STANDARD” token format, as simple as that.

Token Standard	Format	Protocol Specific	Year of standardization
Kerberos Ticket	Binary	Yes, Kerberos	1993
SAML Token	XML	Yes, SAML	2002
JWT Token	JSON	No	2015

To get a SAML token you need a SAML Server.

To get a Kerberos ticket you need a Kerberos server.

To get a JWT you need something that can give it to you.

Decision point #1) Evaluation criteria

Is the token format standardized?

Can the token be used with any protocol?

Is the token easy to parse?

Can the token be included in URL parameter?

Are there lots of libraries in lots of programming languages for working with the token?

Is the token format considered “easy” to work with?

A ToolBox of Standards

Name	Title
OAuth1	The Oauth 1.0 Protocol
OAuth2	The Oauth 2.0 Authorization Framework
Bearer Token	The Oauth 2.0 Authorization Framework : Bearer token usage
JWE	JSON Web encryption
JWK	JSON Web key
JWA	JSON Web algorithms
JWT	JSON Web tokens
JOSE	JSON object signing and encryption
JWS	JSON Web signature unencoded payload option

JWT:

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

JWT.IO allows you to decode, verify and generate JWT.

OAuth:

OAuth (Open Authorization) is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.[1] This mechanism is used by companies such as Google, Facebook, Microsoft and Twitter to permit the users to share information about their accounts with third party applications or websites.

JWT, OAuth, OpenID Connect and CSRF protection : An understanding

JWT (JSON Web Tokens)- It is just a token format. JWT tokens are JSON encoded data structures contains information about issuer, subject (claims), expiration time etc. It is signed for tamper proof and authenticity and it can be encrypted to protect the token information using symmetric or asymmetric approach. JWT is simpler than SAML 1.1/2.0 and supported by all devices and it is more powerful than SWT(Simple Web Token).

OAuth2 - OAuth2 solve a problem that user wants to access the data using client software like browse based web apps, native mobile apps or desktop apps. OAuth2 is just for authorization, client software can be authorized to access the resources on-behalf of end user using access token.

OpenID Connect - OpenID Connect builds on top of OAuth2 and add authentication. OpenID Connect add some constraint to OAuth2 like UserInfo Endpoint, ID Token, discovery and dynamic registration of OpenID Connect providers and session management. JWT is the mandatory format for the token.

CSRF protection - You don't need implement the CSRF protection if you do not store token in the browser's cookie.

You can read more details here http://proficientblog.com/microservices-security/

If we have to differentiate JWT and OAuth. Basically, JWT is a token format. OAuth is an authorization protocol that can use JWT as a token. OAuth uses server-side and client-side storage. If you want to do real logout you must go with OAuth2. Authentication with JWT token cannot logout actually. Because you don't have an Authentication Server that keeps track of tokens. If you want to provide an API to 3rd party clients, you must use OAuth2 also. OAuth2 is very flexible. JWT implementation is very easy and does not take long to implement. If your application needs this sort of flexibility, you should go with OAuth2. But if you don't need this use-case scenario, implementing OAuth2 is a waste of time.

XSRF token is always sent to the client in every response header. It does not matter if a CSRF token is sent in a JWT token or not, because the CSRF token is secured with itself. Therefore sending CSRF token in JWT is unnecessary.

Decision on whether to go for OAuth or Simple JWT based access to applications:

The key point here is access delegation. Why would anyone create OAUTH when there is an id/pwd based authentication, backed by multifactored auth like OTPs and further can be secured by JWTs which are used to secure the access to the paths (like scopes in OAUTH) and set the expiry of the access

There's no point of using OAUTH if consumers access their resources(your end points) only through their trusted websites(or apps) which are your again hosted on your end points

You can go OAUTH authentication only if you are an OAUTH provider in the cases where the resource owners (users) want to access their(your) resources (end-points) via a third-party client(external app). And it is exactly created for the same purpose though you can abuse it in general

Another important note:
You're freely using the word authentication for JWT and OAUTH but neither provide the authentication mechanism. Yes one is a token mechanism and the other is protocol but once authenticated they are only used for authorization (access management). You've to back OAUTH either with OPENID type authentication or your own client credentials