Skip to main content

OAuth 2.0 Dynamic Client Registration with WSO2 Identity Server

This blog post is about OAuth 2.0 Dynamic Client Registration specified in https://tools.ietf.org/html/rfc7591 and how to register your Application with the WSO2 Identity Server dynamically.

Initially, we have to discover the end user's OpenID provider using OpenID discovery before we are able to use any OAuth service in our Application.

 Step 1: Discovery

In order to do that we must send a request to the OpenID Connect Discovery endpoint specified in https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery using WebFinger. 

WebFinger allows to discover about any entity on the Internet that are identified by a URI that uses standard HTTP. It returns a JSON object which is referred to as JRD (JSON Resource Descriptor).

OpenID Connect Discovery is,

https://localhost:9443/.well-known/webfinger

Since we do not have an access token we can use the admin credentials to the WSO2 Identity Server to send the request as all endpoints of the Identity Server are secured with Basic Authentication.

Following information is required to make the request. 

resource - Identifier for the target end user that is the subject of the discovery request. 
HostServer - Where the WebFinger is hosted.
rel - URI identifying the type of service whose location is being requested.


Request - 
curl -v -k --user admin:admin https://localhost:9443/.well-known/webfinger?resource='acct:admin@localhost&rel=http://openid.net/specs/connect/1.0/issuer'



Response - 


{"subject":"acct:admin@localhost",
"links":[{"rel":"http://openid.net/specs/connect/1.0/issuer",
"href":"https://localhost:9443/oauth2/oidcdiscovery"}]
}


Obtaining the set of Claims about the OpenID Provider

Use the above received href and append /.well-known/openid-configuration to it in order to obtain the set of Claims about the OpenID Provider's configuration, including all necessary endpoints and public key location information.

Request -

curl -v -k --user admin:admin https://localhost:9443/oauth2/oidcdiscovery/.well-known/openid-configuration


Response - 

{
"scopes_supported":["address","phone","email","profile","openid"],
"issuer":"https://localhost:9443/oauth2/token",
"authorization_endpoint":"https://localhost:9443/oauth2/authorize",
"claims_supported":["birthdate","preferred_username","name","phone_number","profile","region","street_address","locality","zoneinfo","locale","sub","gender","formatted","email_verified","updated_at","middle_name","nickname","email","family_name","website","address","phone_number_verified","Organization","given_name","picture","postal_code","country","iss","acr"],
"token_endpoint":"https://localhost:9443/oauth2/token",
"response_types_supported":["id_token token","code","id_token","token"],
"userinfo_endpoint":"https://localhost:9443/oauth2/userinfo",
"jwks_uri":"https://localhost:9443/oauth2/jwks",
"subject_types_supported":["pairwise"],
"id_token_signing_alg_values_supported":["RS256"],
"registration_endpoint":"https://localhost:9443/identity/connect/register"
}

OpenID Connect Dynamic Client Registration

Step 2:
After discovering the Client Registration Endpoint, Application should send a HTTP POST request to the Client Registration Endpoint as below with the client details.

Request -

curl -v -k --user admin:admin -H "Content-Type: application/json" -d '{"redirect_uris": ["https://localhost:9443/callback"],"client_name": "TestApplication","ext_param_owner":"test_owner","grant_types": ["password"]}' https://localhost:9443/identity/connect/register 


Here the grant types can be any of the below,

    

  • authorization_code
    • 

  • implicit
    • 

  • password
    • 

  • client_credentials
    • 

  • refresh_token
    •

Response -

If the Client is registered successfully server will respond with a 201 CREATED.

{
"grant_types":["password"],
"client_secret_expires_at":"0",
"redirect_uris":["https:\/\/localhost:9443\/callback"],
"client_secret":"zDr1LxWx6tHWkTfmYboSoESkQzUa",
"client_name":"admin_TestApplication",
"client_id":"lBJn4yFwYy_90QQ_RUfAUgvN3lEa"
}

If the registration fails, it will return a 400 Bad Request with the error description as follows.

{
"error": "invalid_redirect_uri",
"error_description": "One or more redirect_uri values are invalid"
}


References


Labels:

Comments

Post a Comment

Popular posts from this blog

Admin panel of a Q & A Forum

In a Q & A Forum, when a user posts a question, it should be sent to the administrator for approval in case it contains inappropriate content. After approval it should be removed from this pending approval page and other users should be able to see the question afterwards. To enable this, we should maintain an approval column in our database table of records and for each record approval should be set to false by default. In the Pending approvals page only the records with approval=false should be displayed. Below is  the MySQL  statement for retrieval, $sql="SELECT * FROM topics WHERE approval=false"; To know which post was approved we should embed the post_id to the URL. And the relevant post should be updated as approval=true. Below is the complete code. <?php $sql="SELECT * FROM topics WHERE approval=false"; $query=mysqli_query($conn,$sql); echo '<form name="approve" method="p...
Post a Comment
Read more

Getting Started with OAuth 2.0 using WSO2 Identity Server 5.3.0 and Playground2 Sample

This blog post provides step by step instructions for trying out OAuth 2.0 using WSO2 Identity Server . Here I use Identity Server 5.3.0 which is the latest released version by the time of this writing. The official documentation for this is available in https://docs.wso2.com/display/IS530/OAuth+2.0+with+WSO2+Playground , however for a beginner, it does not provide all the instructions such as creating a Service Provider with necessary configuration. However, by following the steps below, you can simply setup Identity Server and the playground2 sample webapp and test the entire OAuth 2.0 flow. Creating the Service Provider First step is to create a service provider in Identity Server. This is required because when a client application talks to Identity Server via OAuth 2.0, Identity Server has to identify the client and the incoming traffic. We set this configuration inside the service provider. Login to the Management Console of Identity Server and create a service provi...
1 comment
Read more

Interacting with an Ethereum Smart Contract using Meteor and Ethereum

This blog post contains steps on how to interact with a specific contract on the blockchain extending the application created in the previous blog post [1]. Step 1: Add  frozeman:template-var This is used since we use callback very often. This wrapper can be found at [2]. Give the following command in order to add it to our application. meteor add frozeman:template-var Step 2: Adding the balance to be viewed inside the template Alter your code as below. main.js main.html When you refresh the browser, you should get the below output without having to click the button. Step 3: Writing the Smart Contract in Solidity Solidity is the language that ethereum uses to write smart contracts. In order to write the smart contract for our application we will use the online Solidity compiler which can be found at [3]. Step 4: Deploying the Smart Contract Log in to the MetaMask and make sure you are on the testnet. Select 'Create' in the right side p...
Post a Comment
Read more