Open to how it can be improved. What information do you think would be
helpful? ( we may be too close to the situation to know what's missing )
On Tue, Sep 24, 2013 at 11:38 AM, Antonio Sanso wrote:
> Hi Chuck,
>
> On Sep 24, 2013, at 6:56 PM, Chuck Mortimore
> wrote:
>
> What you're descr
Hi Chuck,
On Sep 24, 2013, at 6:56 PM, Chuck Mortimore wrote:
> What you're describing is exactly what the JWT bearer flow specs out
>
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer
>
> We've got the exact same flow, and there are other implementations out there.
> http://login.s
What you're describing is exactly what the JWT bearer flow specs out
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer
We've got the exact same flow, and there are other implementations out
there.
http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm
On Tue, Sep 24, 2013
Just looking at your subject line, and I may have this wrong but are you not
asking about chaining? In server to server you need a way for the second server
to accept a token from the first to propagate the authorization correct?
Phil
> On Sep 24, 2013, at 5:08, Antonio Sanso wrote:
>
> Hi *,
On Sep 24, 2013, at 5:22 PM, Bill Mills wrote:
> So they are using client authentication as defined on OAuth 2 then?
good point indeed :) My main point is that all the pieces of the puzzle to
solve this scenario are probably there beetwen the OAuth core the JWT and the
JWT bearer token speci
So they are using client authentication as defined on OAuth 2 then?
On Tuesday, September 24, 2013 8:18 AM, Antonio Sanso wrote:
Hi chuck,
On Sep 24, 2013, at 4:57 PM, Chuck Mortimore wrote:
I'm not sure I understand your point here. I don't believe there is anything
custom or special
Hi chuck,
On Sep 24, 2013, at 4:57 PM, Chuck Mortimore wrote:
> I'm not sure I understand your point here. I don't believe there is
> anything custom or special about the google implementation here vs JWT. It
> looks identical to our implementation.
>
> Can you elaborate?
sure.
What
I'm not sure I understand your point here. I don't believe there is
anything custom or special about the google implementation here vs JWT.
It looks identical to our implementation.
Can you elaborate?
- cmort
On Sep 24, 2013, at 5:57 AM, Antonio Sanso wrote:
Hi Brian,
thanks a lot for your
Hi Brian,
thanks a lot for your pointer.
What the custom Google flow provides more than the oauth jwt bearer draft is
IMHO an explicit way to build JWT without any 'human interaction' so a server
can handle the construction of an expired JWT bearer token on his own.
This can of course be figur
Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what
you're looking for?
On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso wrote:
> Hi *,
>
> apologis to be back to this argument :).
>
> Let me try to better explain one use case that IMHO would be really good
> to have in the
Hi *,
apologis to be back to this argument :).
Let me try to better explain one use case that IMHO would be really good to
have in the OAuth specification family :)
At the moment the only "OAuth standard" way I know to do OAuth server to server
is to use [0] namely Resource Owner Password Cred
11 matches
Mail list logo
