OAuth2 allows to third-party applications to get access to restricted resources using HTTP protocol. RFC 6749 covers OAuth2 specification. There are 4 roles:

• Client
• Resource Owner
• Authorization Server
• Resource Server

OAuth2 Flow

 (A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary.

(B) The client receives an authorization grant, which is a credential representing the resource owner's authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.

(C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant.

(D) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.

(E) The client requests the protected resource from the resource server and authenticates by presenting the access token.

(F) The resource server validates the access token, and if valid, serves the request.

OAuth2 WebSockets

sgcWebSockets supports Bearer tokens in WebSocket client component. You only must enable Authentication and Token property in TsgcWebSocketClient and set which token will be sent when client connects to server.

 Next version, sgcWebSockets 4.3.4, a new component for OAuth2 will be released and will be able to get OAuth2 credentials automatically.