Hi Tharika,
+1. Have you thought about a way to fetch/update a DCR application?
There is a way you can achieve this by providing an access_token and
registration URL upon DCR registration. So then users can persist that
access_token and URL and can be used in future in order to edit the DCR
application. This approach has currently used by MITRED identity server's
DCR endpoint. [1].
For example: When you register a DCR application, the response payload may
be something like below,
{ "client_id": "4547fc03-a6f3-4641-8e1f-84eb13093e5c", "client_secret":
"ANcxv7xx00H9yO-8dg2-avCKBcqdeK3E-1d-yboYYX3J-rAoGLDaXLPJzR6u7mZAEnhgavbxE0fAm6vfeDy9QiM",
"client_secret_expires_at": 0, "client_id_issued_at": 1407892001, *
"registration_access_token":
"eyJhbGciOiJSUzI1NiJ9.eyJhdWQiOlsiNDU0N2ZjMDMtYTZmMy00NjQxLThlMWYtODRlYjEzMDkzZTVjIl0sImlzcyI6Imh0dHA6XC9cL2xvY2FsaG9zdDo4MDgwXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJqdGkiOiI3MWI2MDlhYi00NmExLTQxMzItOTdkZC05Y2RmYTY0NDEyY2QiLCJpYXQiOjE0MDc4OTIwMDF9.SvJEMThaCmBj5qdl-NibA9UyAKf2uvOqdewYeOh7nHcziiZVIVOrhozfQEgK31OWmmdWxmw3cB2wMqhadqP4mPJGr7gpLIq0N4WF-2zVpPDJZhT7BZESpiKGwXEYiGHYE1xPsd8nKaGuXFKW9U3U31kTG9Ud5BeKxaAgs1lZAGM",
"registration_client_uri":
"http:\/\/localhost:8080\/IDP\/register\/4547fc03-a6f3-4641-8e1f-84eb13093e5c",*
"redirect_uris": [ "google.com" ], "client_name": "Simple Web App",
"contacts": [ ], "token_endpoint_auth_method": "client_secret_basic",
"scope": "phone openid offline_access address email profile",
"grant_types": [ "authorization_code", "refresh_token" ], "response_types":
[ "code" ], "application_type": "web", "default_acr_values": [ ],
"request_uris": [ ] }
To fetch a DCR application data you can use a GET request something like
below. What is your plan?
http://localhost:8080/openid-connect-server-webapp/dcrenpoint/<Client_ID>
Authorization:Bearer <registration_access_token.>
Further, Are we going to have an introspection endpoint for this
implementation?
For the security, The spec [2] says to use an initial access_token to
protect the endpoint. This need to be discussed more.
[1] https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server.
[2] https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-30#page-33
On Thu, Feb 4, 2016 at 10:22 AM, Tharika Madurapperuma <[email protected]>
wrote:
> Hi All,
>
> We are planning of $subject.
>
> In some use cases, it is desirable or necessary to allow OAuth clients to
> obtain authorization from an authorization server without the two parties
> having previously interacted. Therefore in order for the authorization
> server to accurately represent to end users which client is seeking
> authorization to access the end user’s resources, a method for automatic
> and unique registration of clients is needed. This is where the Dynamic
> Client Registration protocol comes into play.
>
> The RFC related to this feature can be found in [1]
>
> *Problem*
>
> Currently, we have implementations for DCR in products like WSO2 API
> Manager and WSO2 Enterprise Mobility Manager. This leads to a duplication
> of the functionality. Since this feature should ideally reside in the WSO2
> Identity Server, we are trying to move it to their code base so that it
> will be available to the entire WSO2 platform.
>
> *Solution*
>
> We are trying to implement it so that the endpoint for registering and
> unregistering an OAuth client will be available through the oauth2 web app
> being deployed through the Identity Server.
>
>
> This feature is implemented as an OSGi service. The endpoint details will
> be as follows.
>
>
> Registering an OAuth 2.0 client application will take place through a POST
> request to the registration endpoint. For example see the following sample
> request,
>
>
> POST *oauth2/oauthdcr* HTTP/1.1
> Content-Type: application/json
>
> {
> "callbackUrl": "www.google.lk",
> "clientName": "MyApp", //OAuth application name
> "tokenScope": "Production",
> "owner": "admin", //User name of application owner
> "grantType": "password refresh_token", //space separated grant-type
> list
> "saasApp" :true //indicates whether this is a SaaS app or not
> }
>
>
> Upon successful registration you'll receive a json payload including the
> client-name, client-id, client-secret and the callback-url.
>
>
> Similarly unregistering an OAuth 2.0 client application will take place
> through a DELETE request to the registration endpoint with the
> applicationName, userId(username of the application owner) and the
> consumerKey taken in as query parameters in the request.
>
> [1] https://tools.ietf.org/html/rfc7591
>
>
> Tharika Madurapperuma
> Intern - Software Engineering
> WSO2, Inc.
> Mobile : +94777-875-624
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Roshan Wijesena.
Senior Software Engineer-WSO2 Inc.
Mobile: *+94719154640*
Email: [email protected]
*WSO2, Inc. :** wso2.com <http://wso2.com/>*
lean.enterprise.middleware.
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
