As we discussed this endpoint will be secured with Basic Auth. That means anyone who has login permission can create OAuth application in system. If need we may add special permission to create OAuth applications.
There is a profile called open registration for OAuth applications but its vulnerable to DoS attacks. So we must use some form of authentication. And spec says previously generated token also can use for this. But IMO it will not suitable for our requirement. @Roshan, Yes that is the proper way of getting resource data according to Richardson maturity model for REST APIs.We provide resource ID and do get to fetch resource. I think we may add it for users to get data later. They can change grant types, scopes or app name by logging to management console. May be later we can support edit application with this web application. But as of now we focused on create and delete part only. But definitely we need to look at edit option as well. In that case we need to check user name and verify if app owner is edit app or not. Otherwise anyone can edit other peoples apps. Registration endpoint may named as oauth2/dcr or oauth2/register. @Amila, having register is mandatory for registration URL? If we let users to edit/delete as well then having resource name as "register" may be bit of confusing. And most important thing this registration endpoint should secured with TLS 1.2 as per spec section 5[ https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-30#section-5]. Thanks, sanjeewa. On Fri, Feb 5, 2016 at 12:34 AM, Amila De Silva <[email protected]> wrote: > Hi Tharika, > > Since *"**saasApp"* is not a common parameter as per the spec, you might > have to emphasise the usage of it. > > Just noticed that in the excerpt you've provided request is sent to a > resource named oauthdcr. Better if we can name it as /regsiter to show > the conformity with the spec. > > On Thu, Feb 4, 2016 at 9:52 PM, 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 >> >> > > > -- > *Amila De Silva* > > WSO2 Inc. > mobile :(+94) 775119302 > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
