Microservices Advanced Online Training
In Microservices Advanced online training: OAuth2 is both Authentication(AuthN) and Authorization(AuthZ) framework that enables third-party application (such as Redbus) to automatically login to third-party application by using Twitter or Facebook or LinkedIn or Google or GitHub credentials. i.e., the OAuth works by delegating user authentication process to Twitter or Facebook or LinkedIn or Google or GitHub and then automatic login to third-party application after authorizing third-party application.
Through OAuth login, our application obtains limited access on Twitter or Facebook or LinkedIn or Google or GitHub resources than direct login to social. Microservices architecture says decompose single project into many smaller services. But we cannot ask the end user to sign-up and sign-in to every microservice. Instead the end user prefers single sign-on irrespective of number of microservices. Different microservices will run on different embedded servers. Hence there is no common session id. That means we cannot use session id across different microservices to represent user’s identity. Instead of using session id, rather use common oauth token across all microservices to represent user’s identity. The oauth token was generated by Authorization server and validated by Resource server. Both Authorization server and Resource server together called as OAuth provider. We can use either existing OAuth providers (such as Twitter or Facebook or LinkedIn or Google or GitHub) OR implement our own OAuth Provider. Since each microservice should perform token validation hence it is advised to implement our own OAuth provider. Otherwise if we use existing OAuth providers (such as Twitter or Facebook or LinkedIn or Google or GitHub) then every microservice should perform token validation against them in internet which is expensive. Hence in microservices projects, it is recommended to implement our own OAuth provider.Conclusion: OAuth 2.0 is a delegation protocol, a means of letting someone who controls a resource allow a software application to access that resource on their behalf without impersonating them.
What Will You Learn?
- OAuth 2.0
- OAuth 2.0 Client
- Microservices Security with OAuth
- JSON Web Token (JWT)
- API Gateway using Zuul
- API Gateway and OAuth
- Microservices with AWS
Pre-Requisites
- Spring
- Spring Microservices
Curriculum
-
OAUTH 2.0
-
Day :Introduction
-
Day :Client Registration
-
Day :Client Identifier
-
Day :Client Password
-
Day :Client Authentication
-
Day :Protocol Endpoints
-
Day :Authorization Endpoint
-
Day :Token Endpoint
-
Day :Scope
-
Day :OAuth Protocol Flow
-
Day :Grant Types
-
Day :Authorization Code Grant Type
-
Day :Implicit Grant Type
-
Day :Password Grant Type
-
Day :Client Credentials Grant
-
Day :Refresh Token Grant Type
-
Day :Redis Token Store
-
Day :Database Token Store
-
Day :Separating Authorization and Resource servers
-
Day :Authorization Server
-
Day :Resource Server
-
-
OAuth 2.0 CLIENT
-
Day :Client Authorization Code
-
Day :Client Password
-
Day :Client Client-Credentials
-
Day :Client Implicit
-
-
Microservices Security With OAuth
-
Day :Fares MicroService
-
Day :Search Microservice
-
Day :Booking Micorservice
-
Day :CheckIn Microservice
-
Day :PSS Website
-
-
JSON Web Token (JWT)
-
Day :Introduction
-
Day :Header
-
Day :Payload
-
Day :Signature
-
Day :Verifying JWT
-
Day :Microservices with JWT
-
Day :Authorization Server with Symmetric Key
-
Day :Micro Services with Symmetric Key
-
Day :Authorization Server with Asymmetric Key
-
Day :Micro Services with Asymmetric Key
-
-
API Gateway using zuul
-
Day :API Gateway using Zuul
-
-
API Gateway and OAuth
-
Day :API Gateway and OAuth
-
-
Microservices with AWS
-
Day :Microservices with AWS
-