After completing its interaction with the resource owner, the authorization server directs the resource owner's user-agent back to the client. The authorization server redirects the user-agent to the client's redirection endpoint previously established with the authorization server during the client registration process or when making the authorization request.
The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication. The client identifier is unique to the authorization server. The client identifier string size is left undefined by this specification. The client should avoid making assumptions about the identifier size. The authorization server SHOULD document the size of any identifier it issues.
The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. The value of the scope parameter is expressed as a list of space- delimited, case-sensitive strings. The strings are defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope.
scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E )The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted. If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined).
Next you will be redirect to the authorization endpoint which you provided.
At the authorization server you might ask for your account credentials if you have not logged-in before or your session has expired, If you already have a valid session for the authorization server you will be redirect request permission page.
You can experience the flow of OAuth 2 authorization by selecting either of the product listed
You don't want to have any keys, tokens ect.
In this scenario you will consider as Resource Owner, Where you will authorize this application (OAuth playground) to request to protected resource of you from the Resource Server(Either Facebook or WSO2 APIM) through your browser Client. During the process OAuth playground application will send multiple authorization request to your Authorization Server based on the selection below.
You can try the playgroun app as a developer as well.You need fill all the required fields in order to try the app. If you are running this application in your local setup, You can refer to console logs for information about sensitive data , such as Client Secret Access Token and Authorization Code and etc.. You can change the log level from