2 legged OAuth about oauth2-server-php

[bshaffer]

That is correct. Oauth primarily exists for the use case of three legged
oauth. You can implement two legged oauth still... The "password grant" is
a good example of this. But it wil require an extra round trip request (ie
you will always need a specific request to obtain the token). Hope this
helps!

Brent

On Wednesday, January 9, 2013, F21 wrote:

I just came across your library and would like to implement it into my
application to support OAuth 2.

I am looking to implement 2-legged OAuth for server-to-server
authorization which means that I won't have to send a token with each
request to my application's API.

I am still looking through the source, but does this library support
2-legged OAuth (processing request without a token)?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20.

Sincerely,
Brent Shaffer
@bshaffer http://twitter.com/bshaffer

[F21]

After more research, I have discovered that google uses JWT grant tokens.

Would you be interested in having a grant_type of urn:ietf:params:oauth:grant-type:jwt-bearer added?

[bshaffer]

Yes! That sounds excellent!

[F21]

What are your views on the oauth library requiring third party libraries? I am planning to build a small library to decode/encode JWTs and what not, but it will be a general purpose library.

[bshaffer]

I have no problem including third party libraries where it makes sense to do so!

[F21]

We have a few choices :)

• Directly include it in the repository.
• Use Composer
• Use a git submodule.

Which one would be preferred?

[bshaffer]

Composer

On Thursday, January 10, 2013, F21 wrote:

We have a few choices :)

• Directly include it in the repository.
• Use Composer
• Use a git submodule.

Which one would be preferred?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-12123028.

Sincerely,
Brent Shaffer
@bshaffer http://twitter.com/bshaffer

[F21]

I have gotten most of the code implemented for JWT support. The only problem is that the OAuth server always calls getClientCredentials to check if there is Basic Auth headers or client_id and client_secret in the GET parameters or POST parameters.

This is a problem, because JWT only requires me to send grant_type and an assert which contains the payload. The payload is then decode to get at the data inside.

Have you got any ideas on how to modify the server so that it supports this condition?

[F21]

One possible solution could be to add an extra method to OAuth2_GrantTypeInterface called checkAuthenticationHeaders().

This would then return true or false for each grant type. Then before calling getClientCredentials() in grantAccessToken() in the GrantController, we first call that method to check if the GrantType requires us to check the Authentication header.

What do you think?

[bshaffer]

So it seems that in order to use JWT as client validation, a client_assertion_type parameter needs to be supplied. So, this is actually entirely separate from the grant type. See this example here:

http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04#page-5

Where the client assertion is JWT, but the grant type is still authorization_code. So I believe we just need a new interface for OAuth2_AssertionType, and have OAuth2_AssertionType_HttpBasic and OAuth2_AssertionType_JWT. The server defaults to HttpBasic if no client_assertion_type parameter is supplied.

[F21]

Hi there,

From my understanding using JWT as an authorization grant is completely unrelated to using it as client authentication.

In this case (when using it as an authorization grant), we do not need any of the to check the authentication headers at all as per 2.1 of the spec. Since we can identify/authenticate the request by its signature. Salesforce provides a pretty good description of the steps to perform authorization grant using JWTs.

In this case wouldn't we still need to make a change so that the authentication headers are not checked?

Re: modifying OAuth2_AssertionType

I am not 100% what needs to be done here as I am still don't know my way around the code base very well. Would you be able to implement the required changes for that, so I can implement JWT as client authentication?

[bshaffer]

In response to your first three paragraphs, you are correct, and we are on the same page.

If you will implement the JWT client library, I can work to help you integrate it, yes.

[F21]

I am almost done with the JWT grant type (except for finding a way to ask the library to not check for the authentication headers). A lot of tests have also been written :)

Are you happy with me adding a checkAuthenticationHeaders() to OAuth2_GrantTypeInterface? This will be called before the headers are checked and if it returns true, the headers are checked, otherwise they are not.

Let me know what you think :)

[F21]

Another thought: Since we will have a JWT grant type and a JWT client authentication, I think it makes sense to fully integrate the JWT library into the library (instead of having it as a composer requirement). This way, I can move all the code for verifying a JWT into the JWT library.

Let me know what you think :)

[bshaffer]

It sounds like you should add a different Token Type (JWT) to handle the authentication headers.

[F21]

I couldn't find anything in the spec about a token_type for JWT though. It seems that for JWT we still use a token_type of `bearer.

Having said that, if the token_type was to be passed in via $config in the __contruct() of server.php, we would not be able to ask the server to serve requests for multiple token_types.

[F21]

Oh, and the example in the spec shows that we can only identify the JWT Authorization grant request using the grant_type parameter:

POST /token.oauth2 HTTP/1.1
     POST /token.oauth2 HTTP/1.1
     Host: as.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
     &assertion=eyJhbGciOiJFUzI1NiJ9.
     eyJpc3Mi[...omitted for brevity...].
     J9l-ZhwP[...omitted for brevity...]

[bshaffer]

I think I'm misunderstanding something here. Grant types are only for the GRANT endpoint, and require client credentials. Token Types are for the ACCESS endpoint and determine what the token looks like. I don't understand why we can't use ClientAssertionType on the one hand, and TokenType on the other. This seems like the appropriate approach.

I apologize if I'm missing something, I have not spent nearly enough time with the jwt spec

[F21]

I guess I don't know my way around the code base very well at the moment, so I apologize for the confusion :)

For now, let's just talk about the JWT Authorization grant and not using JWTs as client authentications. We will get to that once Authorization grant has been implemented.

From my understanding, we do not every need to send a request to the /authorize endpoint when we use JWT Authorization Grant. Out of band, we exchange either a client_id and a shared_secret or we generate a client_id and public/private key pair. We then store the public key and send the private key to the client (note that we never store the private key).

To get an access token, the client simply generates a JWT token as per the spec (which is just a bunch of rules for encoding a JSON representation) and generates a signature. The signature is signed by using either the shared_secret or the private key. The JWT is then sent to then endpoint as the assertion parameter.

This is sent to the /token endpoint like so:

     POST /token HTTP/1.1
     Host: as.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
     &assertion=eyJhbGciOiJFUzI1NiJ9.
     eyJpc3Mi[...omitted for brevity...].
     J9l-ZhwP[...omitted for brevity...]

When the server receives the request to /token, it checks the grant_type and loads the appropriate GrantTypeClass to process the request and return an access token.

The catch here is that the request should only contain 2 parameters: grant_type and assertion. There should be no other headers (authentication or anything else).

What the server does, is first decode the assertion's JWT to find the iss property in the token. This iss (issuer) should contain a client_id. The server then looks up up this client_id to find the shared_secret or public key associated with it. The server then verifies the signature that was encoded with the shared_secret using the shared_secret, or if public/private keys are used, it verifies the signature using the public key, since it was encoded using the private key.

This step establishes (authenticates the client) since it verifies his identity. We then move on to check the other properties of the JWT, for example, the expiry, the audience (which is the URL of the OAuth Endpoint) and various other properties.

If all the checks pass, then we issue an access token without a refresh token. Once the token is issued, the client can use the token to gain access using the /access endpoint just as if the access token was issued using any other grant type.

If the access token expires, the client then generates a JWT again (with a new expiry time, etc) and asks the /token endpoint for a new access token.

Now, the problem is this:

The /token endpoint would call the handleGrantRequest() method in Server.php.

This then calls handleGrantRequest() in OAuth2_Controller_GrantController which then calls grantAccessToken().

The problem is that grantAccessToken() always calls $this->getClientCredentials() and checks if it returns a NULL. If it does, it assumes the request is bad or malformed.

In the case of a JWT token, we never send any authentication headers or any client credentials in the body. These things are actually inside the JWT token, which we process in the JWTBearer GrantType class (I have called it OAuth2_GrantType_JWTBearer in my implementation).

Therefore, in order to deal with it, we will need to be able to have $this->getClientCredentials() either return a non-null response if the request is a JWT Authorization Grant (by checking grant_type) or not call to $this->getClientCredentials() if the request is a JWT Authorization Grant (by checking grant_type).

The question is, what's the best way to achieve the above while getting everything to be decoupled and clean :)

I hope that clears things up and I apologize for the long-winded response. Let me know if I have made any mistakes :)

[bshaffer]

Eureka! You sir, have solved my befuddlement! JWT is client assertion and access token in one! So you can use it for one or the other, if you like.

In that case, it is clear the GrantType interface has to be expanded to accomodate for bypassing the client credentials check. Rather than checkAuthenticationHeaders being added to all GrantTypes, it may make more sense to have it assume two interfaces... the GrantType interface but also a ClientAssertionType interface. Then, we can just add a logical check in the code...

if ($grantType instanceof ClientAssertionType) {
    // do something...  I assume we still DO check the client assertion is valid!
} else {
    $clientData = $this->getClientCredentials();
    // and so on...
}

What do you think? Will this get us where we want? Seems like it will also set us up nicely for adding the ClientAssertionType functionality as well!

[F21]

I think that sounds perfect! Definitely a lot cleaner than checkAuthenticationHeaders() I was proposing. Can you implement this and do a commit?

I can then pull and merge then implement this on my end.

Also, what are your thoughts on just embedding the JWT library into the library? It is currently just 1 class anyway, and I feel that I can move all the JWT checking (expiry, audience, etc) into the JWT class which we can also call when we implement JWT Client Authentication down the track. :)

[bshaffer]

I am okay with embedding the library. I will try to implement this as soon as I can, but please don't be shy and feel free to implement it yourself!

I have half a hair to do some "plugin"-style architecture for the extension grants. This is the first extension grant I have seen, so do we add it straight in, or create oauth2-server-extension-jwt? I would prefer the latter, but I don't want to wait on this architecture to add this functionality, so it can wait!

[F21]

I think let's just add the extension grant straight in for now. I am assuming that to implement the plugin architecture, lots of refactoring will be required, which is not exactly trivial. I am happy with adding it straight in for now, and when the plugin architecture is done, we can refactor the code. Much of the code in the extension grants should not require too much refactoring anyway.

I will see what I can do and try and get a pull request out soon :)

[F21]

Done in #25. So Closing.