+1 to the Oauth MAC Token profile soon. Having the Digest auth would also be good - More options for the customer. :)
I found an article Prabath wrote about the benefits of the Oauth MAC profile a few years ago [1]. It's lightweight, more secure than the Oauth 2 bearer token request, and it doesn't need TLS to be secure. [1] https://dzone.com/articles/oauth-20-bearer-token-profile Thanks, Colin Roy-Ehri Software Engineer *WSO2, Inc. : wso2.com <http://wso2.com/>* *Mobile* : 812-219-6517 On Wed, Sep 2, 2015 at 1:05 PM, Prabath Siriwardena <[email protected]> wrote: > In my view - supporting OAuth MAC Token Profile [1] is high priority than > this... > > [1]: https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 > > Thanks & regards, > -Prabath > > On Wed, Sep 2, 2015 at 1:02 PM, Prabath Siriwardena <[email protected]> > wrote: > >> I guess you are talking about the HTTP Digest Authentication as in RFC >> 2617. >> >> The challenge in digest auth is the user store should store passwords in >> cleartext (or encrypted - but not hashed) or should store the hash value of >> username:password:realm. >> >> Thanks & regards, >> -Prabath >> >> On Wed, Sep 2, 2015 at 12:27 AM, Tharika Madurapperuma <[email protected]> >> wrote: >> >>> Hi All, >>> >>> We currently have Basic auth to support secure endpoints in API >>> Manager. We hope to provide a "Digest auth facility" as well, in our next >>> release 1.10, in order to ensure better security. >>> >>> In this feature, the client(The API Developer) will have the >>> ability to select the authentication type he or she requires as either >>> Basic auth or Digest auth. >>> >>> If the client selects Digest auth as the preferred >>> authentication type, the password is never sent over the network in plain >>> text whenever the client requests access to a resource. What we send is >>> only a hash. >>> >>> The following diagram explains the digest authentication process in >>> a nut shell. >>> >>> >>> >>> >>> I will further explain it here. >>> >>> 1. The client sends a request to the backend for accessing the resource. >>> >>> 2. The backend receives the request and sends back a 401 Authentication >>> required message indicating that the client’s request has generated an >>> unauthorized access error. >>> >>> 3. Then the client extracts the required information from the message >>> sent by the backend and generates hashes as shown by the source code below. >>> >>> HA1 = md5(username:realm:password) >>> HA2 = md5(requestMethod:uri) >>> Hash = md5(HA1:serverNonce:nc:cnonce:qop:HA2) >>> >>> The * realm* is a string which is used as part of the hash. It is the >>> name of the domain that contains the account indicated by the user name. >>> >>> The *qop*(Quality Of Protection) can be one of auth, auth-int etc. and >>> has influence on how the hash is created. We use auth here. >>> >>> The *serverNonce* is a unique code, which is used within the hash and >>> needs to be sent back by the client to the backend. >>> >>> The above are the essential information gathered from the 401 response >>> sent by the backend. >>> >>> Then the *username* and the *password* supplied by the client, the >>> realm, the serverNonce and the qop sent by the backend are used for the >>> creation of the hash along with the following as well. >>> >>> The *nc* is the Nounce count which is a hexadecimal serial number for >>> the request. The client should increase this number by one for every >>> request. It is the number of times the client has sent a challenge response >>> by using the nonce. The nonce must be specified if a "qop" directive is >>> sent. >>> >>> The * cnonce* is a unique id generated by the client. This nonce >>> represents a challenge issued by the client to the server when immediate >>> authentication of the server is desired. It can also be used to chosen >>> plain text attacks. >>> >>> The *uri* is the authentication uri of the requested resource and the >>> *request >>> method* can be one of GET, POST, etc. >>> >>> 4. The final Hash generated here is then sent to the backend for >>> authentication, incorporated in an authentication header along with the >>> following content. >>> >>> The username, realm, serverNonce, uri, qop, nc and cnonce. Note that the >>> password is not sent along with these information. >>> >>> 5. Then the backend will respond accordingly with respect to the >>> validity of the authentication. >>> >>> The hash cannot be decrypted. Therefore the backend does this check by >>> applying the same hashing procedure with the password stored in the >>> database of the backend. If the hashes match, access is granted to the >>> requested resource. >>> >>> >>> Tharika Madurapperuma >>> Software Engineering Intern >>> WSO2 >>> Mobile : +94777-875-624 >>> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Twitter : @prabath >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >> >> Mobile : +1 650 625 7950 >> >> http://blog.facilelogin.com >> http://blog.api-security.org >> > > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://blog.facilelogin.com > http://blog.api-security.org > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
