On Tue, Jan 9, 2018 at 8:29 AM, Isura Karunaratne <[email protected]> wrote:
> > > On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee <[email protected]> > wrote: > >> The idea behind this is to decouple the authentication mechanism used by >> OAuth2 clients from the rest of the OAuth2 logic, so that different types >> of client authenticators can be plugged. For an example according to >> specification [1] client_secret_basic, client_secret_post, >> client_secret_jwt are few client authentication mechanisms. >> >> The client authentication will be done through an extension. Hence >> different client authentication criteria can be implemented and can be >> plugged. >> >> The interface (API) will consist of three main methods. >> >> 1) canAuthenticate - Decides whether the particular authenticator can >> authenticate the incoming request or not. >> >> 2) authenticateClient - Authenticates the client request based on >> information present. As a result of authentication client ID will be >> available in the context. >> >> 3) getClientId - Depending on the authentication mechanism they way >> client ID is extracted depends. For an example in JWT client authentication >> client sends out the client Id within the JWT as the subject. Hence in a >> case authenticaiton fails, we may need to extract client Id for other >> puposes. ex - data publishing, if the client is non confidential. >> >> The client authenticator has to be implemented as an OSGI bundle and >> should be deployed in dropins upon building. Also relevant authenticator >> name has to be configured in identity.xml under client authenticators. >> >> <ClientAuthHandlers> >> >> <ClientAuthHandler Class="org.wso2.carbon.identit >> y.oauth2.token.handlers.clientauth.BasicAuthClientAuthHandler"> >> </ClientAuthHandler> >> >> </ClientAuthHandlers> >> > > How are we going to support, non-confidentials clients, will that support > through another ClientAuthHandler? Also, Do we support > backword compatibity for exsting ClientAuthHandlers? > Client authenticator will only authenticate if the application is confidential. If not, still a client authenticator can be introduced to extract client ID. If no authenticator can handle (either authenticate/ extract client ID) it will try to extract client ID from the body of the request and allow to go forward if it's non confidential. Otherwise it will fail. Most probably there will be a code migration required since there will be subtle changes in client authenticator interface. Ideally as per the current way there shouldn't be much custom client auth handlers implemented since the authentication was tightly coupled to the rest of the flow. > > > Thanks > Isura >> >> >> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli >> entAuthentication >> <http://www.google.com/url?q=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23ClientAuthentication&sa=D&sntz=1&usg=AFQjCNEcVTdgiIUSObwbxp8OUtTU1By8Rg> >> >> >> >> >> >> >> -- >> Hasintha Indrajee >> WSO2, Inc. >> Mobile:+94 771892453 <077%20189%202453> >> >> > > > -- > > *Isura Dilhara Karunaratne* > Associate Technical Lead | WSO2 > Email: [email protected] > Mob : +94 772 254 810 <077%20225%204810> > Blog : http://isurad.blogspot.com/ > > > > -- Hasintha Indrajee WSO2, Inc. Mobile:+94 771892453 <077%20189%202453>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
