On 12/19/2011 10:20 AM, Paul Madsen wrote:
our bearer access tokens (JWT formatted) encapsulate a set of content
permissions, and serve to authorize the entity presenting them to the
corresponding video content.
We dont want those tokens falling into the wrong hands, and so want to
prevent an attacker being able to impersonate a valid client and trade
an authz code for the token.
*Ideally*, all our clients would be confidential, and so capable of
authenticating to the AS to prevent/mitigate the above risk
If there's any incentive at all to decompile an .apk (for example) and steal
the client secret, you can be guaranteed that somebody will do that.
Consider also that most developers area going to use whatever sample
code there is and do just about nothing to hide the key as best they
can regardless of how many warnings you put in your sample code.
So the attack is not likely to even be particularly difficult. Is it really
too much to ask app developers to spend $7/month for a shared hosting
service to keep their client secret a lot more secure?
Another thing to consider: in your client enrollment process how would
you insure/police that they are actually in compliance that it actually is
actually coming from confidential client?
Mike
thanks
paul
On 12/19/11 1:00 PM, Michael Thomas wrote:
On 12/19/2011 09:50 AM, Paul Madsen wrote:
Hi Mike, to some extent I think my question is not about specific
security characteristics, but rather whether its realistic for our
group to mandate that both server & native clients have the *same*
security characteristics - particularly the ability to 'securely'
authenticate to the AS on the token endpoint.
Well given the explanation Justin just gave, they do not. As I
understand
your initial query, redefining a native/embedded app as
"confidential" doesn't
alter that reality. But my first question about requirements still is
relevant:
what are you trying to protect from whom, and what is the level of
risk that
your profile of oauth is willing to tolerate?
Mike
thanks
paul
On 12/19/11 12:18 PM, Michael Thomas wrote:
On 12/19/2011 04:19 AM, Paul Madsen wrote:
Hi, the Online Media Authorization Protocol (OMAP) is a (as yet
unreleased) profile of OAuth 2.0 for online delivery of video
content based on a user's subscriptions (the TV Everywhere use case)
We want to support both server & native mobile clients. It is for
the second class of clients that I'd appreciate some clarification
of 'confidentiality' as defined in OAuth 2.
OAuth 2 distinguishes confidential & public clients based on their
ability to secure the credentials they'd use to authenticate to an
AS - confidential clients can protect those credentials, public
clients can't.
Notwithstanding the above definition, the spec gives a degree of
discretion to the AS
The client type designation is based on the authorization
server's
definition of secure authentication and its acceptable exposure
levels of client credentials.
Give this discretion, is it practical for the OMAP spec to
stipulate that 'All Clients (both server & native mobile), MUST be
confidential', ie let each individual OMAP AS specify its own
requirements of clients and their ability to securely authenticate?
Hi,
Can you say exactly what your security requirements are before
trying to determine which
(if either) is the right answer? I've got some concerns in this
area that I'm trying to understand
and am not sure if they're related to your concern or not. Part of
this is that I really don't
understand what the difference is between a "public" client and a
"confidential client" and
rereading the draft isn't helping me. In particular, can a iPhone
app with a UIWebView *ever*
be a "confidential" client, and if so how?
Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
