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
