On 03/07/2014 20:09, Sean McArthur wrote:
No response means you're all absolutely awestruck by its genius, right?
Andy, I was told the Marketplace has some oauth-like functionality that
we want to shift into our system. Any 3rd parties that would be
interested taking a look at this?
Nice writeup Sean! I'm trying to piece together the full flow and have
some questions regarding revised steps 5-7, and how everything works
from an RPs perspective. I'm a new to a lot of this, so many of my
questions are probably n00b related.
IIUC, the core problem you are trying to solve arises because the user
is being asked to grant the RP authorization to two distinct service
providers in a single oauth transaction, and a single token would allow
one service provider to masquerade as the user at the other service
provider?
Pasting in steps 5-7 for reference:
==============================
> 5. Cuddly Foxes first verifies that the returned state is one they
sent. They generate a new ed25519 keypair for this user+scope, and then
sends the pubkey, the code, and the client_secret they received at
registration to the server. This registers that public key with our
OAuth service.
> 6. Our server will verify the client_secret matches what is
associated with the code, save the public key, and return the scopes
that have been approved.
> 7. Cuddly Foxes would then use that private key to sign a request
asking for the user’s email address, from our Profile server, since
that’s the scope that was asked for.
==============================
Going back in the article a little to the problem this is trying to solve:
==============================
> That means that they ask our OAuth server for a token with scopes
‘profile:email’ and ‘foxcoin’. With the token in hand, they ask the
Profile server for the user’s email, providing said token as proof that
they can receive profile information, and they receive it. But! The
profile server just received a token that it can use to access the
user’s FoxCoin information, acting as Cuddly Foxes. Yikes!
> Of course, we can assume the Profile server wouldn’t do anything so
nefarious, but having that power is still dangerous. And imagine as we
add in more 3rd-party attached services, which inherently are less
trustworthy. Additionally, with the recent discovery in OpenSSL, we
don’t want to trust TLS alone to protect against sniffing the data as it
passes. So, passing around a Bearer token in plain text is unacceptable.1
==============================
First off, what is the crypto being used for? I think the answer is this
sentence:
> The next step was to consider using a secret token to sign a request,
so that the original token is never revealed.
In step 4, the RP receives a token from the OAuth server. In step 5, the
RP takes that code, creates a pub/priv keypair, creates a bundle with
the pubkey, the code, and the client_secret, signs the bundle with the
privkey and ships it to the OAuth server? Does the RP then have to store
the pub/priv key for this user/scope combination for all of eternity, or
is this client side only? If the priv key is sent to the RP, what
threats exist if their server is compromised? What happens if the user
is asked to re-authorize, is the same pub/priv key used, or is a new one
generated? Can the OAuth provider masquerade as the user anywhere they like?
In step 6, what happens if the OAuth server already has a pubkey stored
for the user/scope combination, does it reject the new one, clear the
old one or store them both? If there are multiple keys stored, are old
ones ever ejected?
In step 7, instead of passing the original token, the RP creates a new
bundle that contains an encrypted/hashed version of the original token
along with the scope? What info does the Profile server use to actually
ensure the request is authorized? Does the Profile server need to share
state with the OAuth server?
I'm going on to step 8 - requesting info from FoxCoin, is it a repeat of
step 7, just with a different service provider?
Is there any notion of expiration? If my device has a magic priv key to
FoxCoin, and then is stolen, will the thief forever have access to my
FoxCoin account?
What new requirements are imposed on an RP that are not already imposed
by OAuth? It sounds like a ed25519 library, and potentially storing
pub/priv keys? Are vetted ed25519 libraries readily available for
popular languages?
Thanks Sean!
Shane
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
