What you suggest below is essentially what John Bradley proposed as a
"holder of key" JWT a while ago. The main difference between the two
approaches is that mine can also cover aspects of the HTTP request
itself in the signature. I think you could do both of them together by
simply making the
On Sat, Oct 26, 2013 at 6:03 PM, Richer, Justin P. wrote:
> >> On our backlog is also support for "service accounts" (to use
> Google's terminology), so clients will likely need to do some
> crypto-related work. Asking them to do it for each and every request to
> sign the access token might not
>> On our backlog is also support for "service accounts" (to use Google's
>> terminology), so clients will likely need to do some crypto-related work.
>> Asking them to do it for each and every request to sign the access token
>> might not be that
>
>
> I assume you mean signing the request or a
Le 25 oct. 2013 19:28, "Torsten Lodderstedt" a
écrit :
>
>
> Am 25.10.2013 11:19, schrieb Thomas Broyer:
>>
>>
>>
>>
>> On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
>>>
>>> Hi Thomas,
>>>
>>> we generate access tokens per resource server in order to mitiga
Am 25.10.2013 11:19, schrieb Thomas Broyer:
On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
Hi Thomas,
we generate access tokens per resource server in order to mitigate
this and other risks. You must issue those tokens to different
On Thu, Oct 24, 2013 at 4:36 PM, Richer, Justin P. wrote:
> On Oct 23, 2013, at 5:27 PM, Thomas Broyer
> wrote:
>
> On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. wrote:
>
>> Hi Thomas,
>>
>> You're right in that the introspection process is about getting meta
>> data about a particular t
On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Thomas,
>
> we generate access tokens per resource server in order to mitigate this
> and other risks. You must issue those tokens to different audiences
> (resource server id) and the resource servers must
On Oct 23, 2013, at 5:27 PM, Thomas Broyer
mailto:t.bro...@gmail.com>>
wrote:
On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P.
mailto:jric...@mitre.org>> wrote:
Hi Thomas,
You're right in that the introspection process is about getting meta data about
a particular token by making an authent
Hi Thomas,
we generate access tokens per resource server in order to mitigate this and
other risks. You must issue those tokens to different audiences (resource
server id) and the resource servers must validate if the token is issued for
its particular audience. Otherwise a compromised resource
On Wed, Oct 23, 2013 at 8:37 PM, Eve Maler wrote:
> Hi Thomas-- You may want to take a look at UMA, which leverages both OAuth
> and Justin's token introspection draft. Token introspection on its own is a
> "shallow" kind of loose coupling between authorization servers and resource
> servers. If
On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. wrote:
> Hi Thomas,
>
> You're right in that the introspection process is about getting meta
> data about a particular token by making an authenticated call. It does
> reveal a lot of information about the token -- because that's exactly the
> p
Hi Thomas,
You're right in that the introspection process is about getting meta data about
a particular token by making an authenticated call. It does reveal a lot of
information about the token -- because that's exactly the point of the
protocol. :)
If the PR is compromised, then the attacker
Hi Thomas-- You may want to take a look at UMA, which leverages both OAuth and
Justin's token introspection draft. Token introspection on its own is a
"shallow" kind of loose coupling between authorization servers and resource
servers. If these are operated by different organizations, as appears
Hi all,
In a platform we're building, we have AS, clients and PRs all as distinct
parties managed/provided by distinct companies. There's a single AS though,
doing SSO through OpenID Connect (i.e. the AS in an OP).
I thus need a way for a PR to ask the AS whether the token presented by the
client
14 matches
Mail list logo
