Hi All,
We have covered three [1], [2], [3] specification(not fully, but mostly
used areas) with this feature.
OAuth application registration and delete
OIDC application registration.
*Client Registration Request*
To register a new Client at the Authorization Server, the Client sends an
HTTP POST message to the Client Registration Endpoint with any Client
Metadata parameters that the Client chooses to specify for itself during
the registration. The Authorization Server assigns this Client a unique
Client Identifier, optionally assigns a Client Secret, and associates the
Metadata given in the request with the issued Client Identifier.
*Sample Request*
POST /identity/connect/register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
{
"redirect_uris": ["server.example.com"],
"client_name": "rest_api_store_1",
"ext_param_owner": "admin",
"grant_types": ["password"]
}
*Response*
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"client_id": "s6BhdRkqt3",
"client_secret":
"ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
"client_secret_expires_at": 1577858400,
"redirect_uris":
["server.example.com"],
"client_name": "admin_rest_api_store_1"
}
*Error Response*
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"error": "invalid_redirect_uri",
"error_description": "One or more redirect_uri values are invalid"
}
*Client UnRegistration Request*
To deprovision itself on the authorization server, the client makes
an HTTP DELETE request to the client configuration endpoint.
DELETE /identity/register/s6BhdRkqt3 HTTP/1.1
Host: server.example.com
Adding ‘client_id’ value as a url path variable.
To implement this, we used our new framework implementation and oidc.dcr
feature was extended by the oath.dcr feature.
Now we have to implement an authentication layer for this and we are trying
to implement it as a valve to make it common to our all the rest api's. But
we have another concern, if we implemented like that, would it be a
performance impact because all the request will go through that even though
those are not belong to this context or not. If it is, then we can write it
in generic way and front to the each rest api separately.
In this case we have to think about the authorization model as well.
[1] https://tools.ietf.org/html/rfc7591
[2] https://tools.ietf.org/html/rfc7592
[3] https://openid.net/specs/openid-connect-registration-1_0.html
thanks
*Harsha Thirimanna*
Associate Tech Lead; WSO2, Inc.; http://wso2.com
* <http://www.apache.org/>*
*email: **[email protected]* <[email protected]>* cell: +94 71 5186770 *
*twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>*
*harshathirimannlinked-in: **http:
<http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
<http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>*
*Lean . Enterprise . Middleware*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
