Posts

Showing posts with the label OAuth2

OAuth vs JWT

The question is an common one, but it isn't quite sensible. JWT is a type of Token, and OAuth is a Framework that describes how to dispense tokens. JWT can absolutely be used as an OAuth Bearer token. In fact, this is the most common practice. In light of that "JWT vs OAuth" is a comparison of apples and apple carts. Often people think "OAuth token"  always  implies an opaque token that is granted by a OAuth token dispensary, that can then be validated only by that same OAuth dispensary system. But this is not the only kind of OAuth token. JWT is just a different kind of OAuth token. Today, the OAuthV2/GenerateAccessToken policy in Apigee Edge generates opaque tokens. It returns a token of 32 seemingly random characters, and the holder has no idea what the token signifies. Therefore, we call it "opaque". To USE the token, the holder must present it back to the token dispensary, because the original dispensary is the only party that can relate the...

@EnableResourceServer Vs (@EnableOAuth2Sso and @EnableOAuth2Client)

OAuth defines four roles: resource owner An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. resource server The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. client An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). authorization server The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. @EnableResourceServer  annotation means that your service (in terms of OAuth 2.0 - Resource Server) expects an access token in order to process...