I am in the process of designing and implementing an architecture in
OAuth to authorize multiple service providers and resources on them
similar to the one Google currently has. I have an initial high level
architecture design here:
I was hoping to get feedback from the members of this board about
potential problems/cases where our architecture would fail and
questions about it so we can better improve upon this design or change
it.
> I am in the process of designing and implementing an architecture in
> OAuth to authorize multiple service providers and resources on them
> similar to the one Google currently has. I have an initial high level
> architecture design here:
> I was hoping to get feedback from the members of this board about
> potential problems/cases where our architecture would fail and
> questions about it so we can better improve upon this design or change
> it.
The scenario that you describe is similar to how services are deployed at Yahoo, where we have dozens (hundreds?) of service providers sharing a centralized Auth service.
In order to support our extremely distributed global architecture, Yahoo services have a hard requirement to be able to validate OAuth credentials without a database lookup. Our service providers are able to verify our Access Tokens locally, by verifying a cryptographic signature and timestamp that is embedded within our Access Tokens.
Additionally, our security policies prohibit any service provider from accepting long-lived persistent credentials. In the event that a service provider is compromised, we want to ensure that the attacker is not able to obtain credentials that can be used to access protected resources after the security vulnerability has been fixed. If our service providers accepted permanent credentials (as is generally the case with OAuth Access Tokens), we'd have to revoke all outstanding Access Tokens in the event of any security compromise, because the attacker may have captured all access tokens (and secrets) during the time the service was compromised.
In order to address these two issues, Yahoo worked with the community to write the OAuth Session Extension which allows SPs to issue Access Tokens with a finite lifetime, as well as an interface for Consumers to automatically refresh an Access Token without any user intervention.
This mechanism allows the Yahoo OAuth service to issue Access Tokens with a relatively short lifetime (1 hour) that can be accepted and validated by any Yahoo Service Provider without a database lookup. Being able to verify credentials locally makes our overall system more robust and faster, and tolerant of network issues between the SP and the central credential database.
From a security perspective, in the unlikely event that a service provider is compromised, we can be confident that any credentials obtained by the attacker have expired an hour after the compromise has ended. Issuing short lived access tokens helps to contain any security breaches within our network and can possibly eliminate the need to do a mass revocation of all credentials in the event of a compromise.
> I am in the process of designing and implementing an architecture in
> OAuth to authorize multiple service providers and resources on them
> similar to the one Google currently has. I have an initial high level
> architecture design here:
> I was hoping to get feedback from the members of this board about
> potential problems/cases where our architecture would fail and
> questions about it so we can better improve upon this design or change
> it.
Hi Allen,
The specs do not have any details on how access tokens are scoped to
specific resources. I've done some searching through the message board
and have not found any specific proposals on how to pass what
resources the token is scoped to when returning the access token to
the consumer. Is this open to implementation or is there any consensus
on how this should be implemented?
> The scenario that you describe is similar to how services are deployed
> at Yahoo, where we have dozens (hundreds?) of service providers sharing
> a centralized Auth service.
> In order to support our extremely distributed global architecture, Yahoo
> services have a hard requirement to be able to validate OAuth
> credentials without a database lookup. Our service providers are able to
> verify our Access Tokens locally, by verifying a cryptographic signature
> and timestamp that is embedded within our Access Tokens.
> Additionally, our security policies prohibit any service provider from
> accepting long-lived persistent credentials. In the event that a service
> provider is compromised, we want to ensure that the attacker is not able
> to obtain credentials that can be used to access protected resources
> after the security vulnerability has been fixed. If our service
> providers accepted permanent credentials (as is generally the case with
> OAuth Access Tokens), we'd have to revoke all outstanding Access Tokens
> in the event of any security compromise, because the attacker may have
> captured all access tokens (and secrets) during the time the service was
> compromised.
> In order to address these two issues, Yahoo worked with the community to
> write the OAuth Session Extension which allows SPs to issue Access
> Tokens with a finite lifetime, as well as an interface for Consumers to
> automatically refresh an Access Token without any user intervention.
> This mechanism allows the Yahoo OAuth service to issue Access Tokens
> with a relatively short lifetime (1 hour) that can be accepted and
> validated by any Yahoo Service Provider without a database lookup. Being
> able to verify credentials locally makes our overall system more robust
> and faster, and tolerant of network issues between the SP and the
> central credential database.
> From a security perspective, in the unlikely event that a service
> provider is compromised, we can be confident that any credentials
> obtained by the attacker have expired an hour after the compromise has
> ended. Issuing short lived access tokens helps to contain any security
> breaches within our network and can possibly eliminate the need to do a
> mass revocation of all credentials in the event of a compromise.
> > I am in the process of designing and implementing an architecture in
> > OAuth to authorize multiple service providers and resources on them
> > similar to the one Google currently has. I have an initial high level
> > architecture design here:
> > I was hoping to get feedback from the members of this board about
> > potential problems/cases where our architecture would fail and
> > questions about it so we can better improve upon this design or change
> > it.
Thanks for directing me to the sessions extension. I have a question
about how you are able to cryptographically verify the access tokens
without doing a database lookup. Wouldn't the local Service Providers
have to have a database of some sort to at least verify a consumer
signature to check for authenticity?
Jack
On Mar 16, 3:38 pm, Allen Tom <a...@yahoo-inc.com> wrote:
> The scenario that you describe is similar to how services are deployed
> at Yahoo, where we have dozens (hundreds?) of service providers sharing
> a centralized Auth service.
> In order to support our extremely distributed global architecture, Yahoo
> services have a hard requirement to be able to validate OAuth
> credentials without a database lookup. Our service providers are able to
> verify our Access Tokens locally, by verifying a cryptographic signature
> and timestamp that is embedded within our Access Tokens.
> Additionally, our security policies prohibit any service provider from
> accepting long-lived persistent credentials. In the event that a service
> provider is compromised, we want to ensure that the attacker is not able
> to obtain credentials that can be used to access protected resources
> after the security vulnerability has been fixed. If our service
> providers accepted permanent credentials (as is generally the case with
> OAuth Access Tokens), we'd have to revoke all outstanding Access Tokens
> in the event of any security compromise, because the attacker may have
> captured all access tokens (and secrets) during the time the service was
> compromised.
> In order to address these two issues, Yahoo worked with the community to
> write the OAuth Session Extension which allows SPs to issue Access
> Tokens with a finite lifetime, as well as an interface for Consumers to
> automatically refresh an Access Token without any user intervention.
> This mechanism allows the Yahoo OAuth service to issue Access Tokens
> with a relatively short lifetime (1 hour) that can be accepted and
> validated by any Yahoo Service Provider without a database lookup. Being
> able to verify credentials locally makes our overall system more robust
> and faster, and tolerant of network issues between the SP and the
> central credential database.
> From a security perspective, in the unlikely event that a service
> provider is compromised, we can be confident that any credentials
> obtained by the attacker have expired an hour after the compromise has
> ended. Issuing short lived access tokens helps to contain any security
> breaches within our network and can possibly eliminate the need to do a
> mass revocation of all credentials in the event of a compromise.
> > I am in the process of designing and implementing an architecture in
> > OAuth to authorize multiple service providers and resources on them
> > similar to the one Google currently has. I have an initial high level
> > architecture design here:
> > I was hoping to get feedback from the members of this board about
> > potential problems/cases where our architecture would fail and
> > questions about it so we can better improve upon this design or change
> > it.
OAuth does not define a standard way for how credentials can be scoped to specific resources. In Yahoo's case, we tie the scopes to the Consumer Key, so that all instances of an application are authorized for the same set of scopes.
In contrast, Google allows consumers to pass the scope field to the SP when requesting authorization. There's no standard way to do this though.
Moses wrote:
> Hi Allen,
> The specs do not have any details on how access tokens are scoped to
> specific resources. I've done some searching through the message board
> and have not found any specific proposals on how to pass what
> resources the token is scoped to when returning the access token to
> the consumer. Is this open to implementation or is there any consensus
> on how this should be implemented?
> On Mar 16, 3:38 pm, Allen Tom <a...@yahoo-inc.com> wrote:
>> Hi Jack,
>> The scenario that you describe is similar to how services are deployed
>> at Yahoo, where we have dozens (hundreds?) of service providers sharing
>> a centralized Auth service.
>> In order to support our extremely distributed global architecture, Yahoo
>> services have a hard requirement to be able to validate OAuth
>> credentials without a database lookup. Our service providers are able to
>> verify our Access Tokens locally, by verifying a cryptographic signature
>> and timestamp that is embedded within our Access Tokens.
>> Additionally, our security policies prohibit any service provider from
>> accepting long-lived persistent credentials. In the event that a service
>> provider is compromised, we want to ensure that the attacker is not able
>> to obtain credentials that can be used to access protected resources
>> after the security vulnerability has been fixed. If our service
>> providers accepted permanent credentials (as is generally the case with
>> OAuth Access Tokens), we'd have to revoke all outstanding Access Tokens
>> in the event of any security compromise, because the attacker may have
>> captured all access tokens (and secrets) during the time the service was
>> compromised.
>> In order to address these two issues, Yahoo worked with the community to
>> write the OAuth Session Extension which allows SPs to issue Access
>> Tokens with a finite lifetime, as well as an interface for Consumers to
>> automatically refresh an Access Token without any user intervention.
>> This mechanism allows the Yahoo OAuth service to issue Access Tokens
>> with a relatively short lifetime (1 hour) that can be accepted and
>> validated by any Yahoo Service Provider without a database lookup. Being
>> able to verify credentials locally makes our overall system more robust
>> and faster, and tolerant of network issues between the SP and the
>> central credential database.
>> From a security perspective, in the unlikely event that a service
>> provider is compromised, we can be confident that any credentials
>> obtained by the attacker have expired an hour after the compromise has
>> ended. Issuing short lived access tokens helps to contain any security
>> breaches within our network and can possibly eliminate the need to do a
>> mass revocation of all credentials in the event of a compromise.
>>> I am in the process of designing and implementing an architecture in
>>> OAuth to authorize multiple service providers and resources on them
>>> similar to the one Google currently has. I have an initial high level
>>> architecture design here:
>>> I was hoping to get feedback from the members of this board about
>>> potential problems/cases where our architecture would fail and
>>> questions about it so we can better improve upon this design or change
>>> it.
A possible implementation would be to sign your credentials using a private key that's only deployed on your Authorization service. All Service Providers that accept your credentials would have the public key to verify the signature. The credentials should contain a timestamp (which is also signed) that indicates when the credentials are due to expire.
At a minimum, the credentials should probably contain the userid, scopes, and a timestamp, with the entire payload signed using your auth server's private key.
> Thanks for directing me to the sessions extension. I have a question
> about how you are able to cryptographically verify the access tokens
> without doing a database lookup. Wouldn't the local Service Providers
> have to have a database of some sort to at least verify a consumer
> signature to check for authenticity?
> Jack
> On Mar 16, 3:38 pm, Allen Tom <a...@yahoo-inc.com> wrote:
>> Hi Jack,
>> The scenario that you describe is similar to how services are deployed
>> at Yahoo, where we have dozens (hundreds?) of service providers sharing
>> a centralized Auth service.
>> In order to support our extremely distributed global architecture, Yahoo
>> services have a hard requirement to be able to validate OAuth
>> credentials without a database lookup. Our service providers are able to
>> verify our Access Tokens locally, by verifying a cryptographic signature
>> and timestamp that is embedded within our Access Tokens.
>> Additionally, our security policies prohibit any service provider from
>> accepting long-lived persistent credentials. In the event that a service
>> provider is compromised, we want to ensure that the attacker is not able
>> to obtain credentials that can be used to access protected resources
>> after the security vulnerability has been fixed. If our service
>> providers accepted permanent credentials (as is generally the case with
>> OAuth Access Tokens), we'd have to revoke all outstanding Access Tokens
>> in the event of any security compromise, because the attacker may have
>> captured all access tokens (and secrets) during the time the service was
>> compromised.
>> In order to address these two issues, Yahoo worked with the community to
>> write the OAuth Session Extension which allows SPs to issue Access
>> Tokens with a finite lifetime, as well as an interface for Consumers to
>> automatically refresh an Access Token without any user intervention.
>> This mechanism allows the Yahoo OAuth service to issue Access Tokens
>> with a relatively short lifetime (1 hour) that can be accepted and
>> validated by any Yahoo Service Provider without a database lookup. Being
>> able to verify credentials locally makes our overall system more robust
>> and faster, and tolerant of network issues between the SP and the
>> central credential database.
>> From a security perspective, in the unlikely event that a service
>> provider is compromised, we can be confident that any credentials
>> obtained by the attacker have expired an hour after the compromise has
>> ended. Issuing short lived access tokens helps to contain any security
>> breaches within our network and can possibly eliminate the need to do a
>> mass revocation of all credentials in the event of a compromise.
>>> I am in the process of designing and implementing an architecture in
>>> OAuth to authorize multiple service providers and resources on them
>>> similar to the one Google currently has. I have an initial high level
>>> architecture design here:
>>> I was hoping to get feedback from the members of this board about
>>> potential problems/cases where our architecture would fail and
>>> questions about it so we can better improve upon this design or change
>>> it.
In addition to the token life time support in the "Session extension" that Allen mentions, there is also a flow that allows an existing token to be "re-authorized" for increased "scope". As Allen points out there is no OAuth "standardized" way to support this, but a deployment with a central IdP and multiple SPs can use this extension to implement this capability.
One way to do this is to have an SP validate the token's it receives with it's IdP specifying the "scope" required for that SP. The IdP validates the token and determines if the user has given authorization for that "scope". If not, the IdP returns an error to the SP, and the SP returns an error to the Consumer... Note that the required "scope" value can also be returned in this response.
The Consumer then repeats the standard OAuth flow as defined in section 6.2 of the "Session Extension" spec.
If you are looking to have a single "access token" work at SPs each relying on their "own" IdP, then there is no support for this at all. This pretty much requires "structured tokens" which as yet have not been addressed by OAuth.
> OAuth does not define a standard way for how credentials can be scoped > to specific resources. In Yahoo's case, we tie the scopes to the > Consumer Key, so that all instances of an application are authorized > for the same set of scopes.
> In contrast, Google allows consumers to pass the scope field to the SP > when requesting authorization. There's no standard way to do this though.
> Allen
> Moses wrote:
>> Hi Allen,
>> The specs do not have any details on how access tokens are scoped to
>> specific resources. I've done some searching through the message board
>> and have not found any specific proposals on how to pass what
>> resources the token is scoped to when returning the access token to
>> the consumer. Is this open to implementation or is there any consensus
>> on how this should be implemented?
>> On Mar 16, 3:38 pm, Allen Tom <a...@yahoo-inc.com> wrote:
>>> Hi Jack,
>>> The scenario that you describe is similar to how services are deployed
>>> at Yahoo, where we have dozens (hundreds?) of service providers sharing
>>> a centralized Auth service.
>>> In order to support our extremely distributed global architecture, Yahoo
>>> services have a hard requirement to be able to validate OAuth
>>> credentials without a database lookup. Our service providers are able to
>>> verify our Access Tokens locally, by verifying a cryptographic signature
>>> and timestamp that is embedded within our Access Tokens.
>>> Additionally, our security policies prohibit any service provider from
>>> accepting long-lived persistent credentials. In the event that a service
>>> provider is compromised, we want to ensure that the attacker is not able
>>> to obtain credentials that can be used to access protected resources
>>> after the security vulnerability has been fixed. If our service
>>> providers accepted permanent credentials (as is generally the case with
>>> OAuth Access Tokens), we'd have to revoke all outstanding Access Tokens
>>> in the event of any security compromise, because the attacker may have
>>> captured all access tokens (and secrets) during the time the service was
>>> compromised.
>>> In order to address these two issues, Yahoo worked with the community to
>>> write the OAuth Session Extension which allows SPs to issue Access
>>> Tokens with a finite lifetime, as well as an interface for Consumers to
>>> automatically refresh an Access Token without any user intervention.
>>> This mechanism allows the Yahoo OAuth service to issue Access Tokens
>>> with a relatively short lifetime (1 hour) that can be accepted and
>>> validated by any Yahoo Service Provider without a database lookup. Being
>>> able to verify credentials locally makes our overall system more robust
>>> and faster, and tolerant of network issues between the SP and the
>>> central credential database.
>>> From a security perspective, in the unlikely event that a service
>>> provider is compromised, we can be confident that any credentials
>>> obtained by the attacker have expired an hour after the compromise has
>>> ended. Issuing short lived access tokens helps to contain any security
>>> breaches within our network and can possibly eliminate the need to do a
>>> mass revocation of all credentials in the event of a compromise.
>>>> I am in the process of designing and implementing an architecture in
>>>> OAuth to authorize multiple service providers and resources on them
>>>> similar to the one Google currently has. I have an initial high level
>>>> architecture design here:
>>>> I was hoping to get feedback from the members of this board about
>>>> potential problems/cases where our architecture would fail and
>>>> questions about it so we can better improve upon this design or change
>>>> it.
On a related note, at the recent Facebook OpenID UX summit, a strong argument was made in in favor of having Consumers initially request a minimum set of privileges, with the ability for the Consumers to upgrade their credentials with additional privileges (with user consent) later.
The example was that a user could install an app and grant it basic privileges (through an un-scary consent UI). After the user tries out the app, the app may require additional (scarier) privileges that the user would more more willing to grant after having used the app with limited privileges. The idea is to not overwhelm the user with excessive amounts of scariness during the initial approval flow.
George Fletcher wrote:
> In addition to the token life time support in the "Session extension" > that Allen mentions, there is also a flow that allows an existing token > to be "re-authorized" for increased "scope". As Allen points out there > is no OAuth "standardized" way to support this, but a deployment with a > central IdP and multiple SPs can use this extension to implement this > capability.
> One way to do this is to have an SP validate the token's it receives > with it's IdP specifying the "scope" required for that SP. The IdP > validates the token and determines if the user has given authorization > for that "scope". If not, the IdP returns an error to the SP, and the SP > returns an error to the Consumer... Note that the required "scope" value > can also be returned in this response.
> The Consumer then repeats the standard OAuth flow as defined in section > 6.2 of the "Session Extension" spec.
> If you are looking to have a single "access token" work at SPs each > relying on their "own" IdP, then there is no support for this at all. > This pretty much requires "structured tokens" which as yet have not been > addressed by OAuth.
> Thanks,
> George
> Allen Tom wrote:
>> Hi Moses,
>> OAuth does not define a standard way for how credentials can be scoped >> to specific resources. In Yahoo's case, we tie the scopes to the >> Consumer Key, so that all instances of an application are authorized >> for the same set of scopes.
>> In contrast, Google allows consumers to pass the scope field to the SP >> when requesting authorization. There's no standard way to do this though.
>> Allen
>> Moses wrote:
>>> Hi Allen,
>>> The specs do not have any details on how access tokens are scoped to
>>> specific resources. I've done some searching through the message board
>>> and have not found any specific proposals on how to pass what
>>> resources the token is scoped to when returning the access token to
>>> the consumer. Is this open to implementation or is there any consensus
>>> on how this should be implemented?
>>> On Mar 16, 3:38 pm, Allen Tom <a...@yahoo-inc.com> wrote:
>>>> Hi Jack,
>>>> The scenario that you describe is similar to how services are deployed
>>>> at Yahoo, where we have dozens (hundreds?) of service providers sharing
>>>> a centralized Auth service.
>>>> In order to support our extremely distributed global architecture, Yahoo
>>>> services have a hard requirement to be able to validate OAuth
>>>> credentials without a database lookup. Our service providers are able to
>>>> verify our Access Tokens locally, by verifying a cryptographic signature
>>>> and timestamp that is embedded within our Access Tokens.
>>>> Additionally, our security policies prohibit any service provider from
>>>> accepting long-lived persistent credentials. In the event that a service
>>>> provider is compromised, we want to ensure that the attacker is not able
>>>> to obtain credentials that can be used to access protected resources
>>>> after the security vulnerability has been fixed. If our service
>>>> providers accepted permanent credentials (as is generally the case with
>>>> OAuth Access Tokens), we'd have to revoke all outstanding Access Tokens
>>>> in the event of any security compromise, because the attacker may have
>>>> captured all access tokens (and secrets) during the time the service was
>>>> compromised.
>>>> In order to address these two issues, Yahoo worked with the community to
>>>> write the OAuth Session Extension which allows SPs to issue Access
>>>> Tokens with a finite lifetime, as well as an interface for Consumers to
>>>> automatically refresh an Access Token without any user intervention.
>>>> This mechanism allows the Yahoo OAuth service to issue Access Tokens
>>>> with a relatively short lifetime (1 hour) that can be accepted and
>>>> validated by any Yahoo Service Provider without a database lookup. Being
>>>> able to verify credentials locally makes our overall system more robust
>>>> and faster, and tolerant of network issues between the SP and the
>>>> central credential database.
>>>> From a security perspective, in the unlikely event that a service
>>>> provider is compromised, we can be confident that any credentials
>>>> obtained by the attacker have expired an hour after the compromise has
>>>> ended. Issuing short lived access tokens helps to contain any security
>>>> breaches within our network and can possibly eliminate the need to do a
>>>> mass revocation of all credentials in the event of a compromise.
>>>>> I am in the process of designing and implementing an architecture in
>>>>> OAuth to authorize multiple service providers and resources on them
>>>>> similar to the one Google currently has. I have an initial high level
>>>>> architecture design here:
>>>>> I was hoping to get feedback from the members of this board about
>>>>> potential problems/cases where our architecture would fail and
>>>>> questions about it so we can better improve upon this design or change
>>>>> it.
On Tue, Mar 17, 2009 at 6:10 AM, Allen Tom <a...@yahoo-inc.com> wrote: > On a related note, at the recent Facebook OpenID UX summit, a strong > argument was made in in favor of having Consumers initially request a > minimum set of privileges, with the ability for the Consumers to upgrade > their credentials with additional privileges (with user consent) later.
That was some thought I also was playing around with.
My use case which I am experimenting with right now is the following:
- you visit a new site - you enter your identity URL (probably your openid) - the site authenticates you and retrieves your service catalogue - the site then asks for authorization of all the services in your service catalogue - it then accesses those services (to retrieve profile info, your friends, your activity stream etc.)
In this scenario you don't want to be redirected to 10 services to give your OK.
I now was toying with the idea of an authorization broker which you authorize once for this new site and which then does the other authorizations (for e.g. basic service levels) automatically for you. This broker could even be your openid server so that you really only have 1 redirect (using the oauth/openid hybrid). I haven't though much about this and the security implications but I think usability suffers quite a bit of you have to do several redirects.
> The example was that a user could install an app and grant it basic > privileges (through an un-scary consent UI). After the user tries out the > app, the app may require additional (scarier) privileges that the user would > more more willing to grant after having used the app with limited > privileges. The idea is to not overwhelm the user with excessive amounts of > scariness during the initial approval flow.
Yep, that's the idea.
It would be nice to have some sort of extension which allows this also for distributed SPs not being under one umbrella.
I am playing right now with the service discovery part and after that I wanted to experiment with that broker idea to see where it leads. I am also not sure if that is actually similar to the diagram in one of the first posts ;-)
Any thoughts or issues on this are of course welcome.
My experiments are located at http://socialconnect.info/ right now and I hope to have some demo up soon.
