Client authenitcation

[errigo]

I have a Native Application (Public Client) which can't store safely a secret to authenticate to the Authorization Server and assertions seem to be the only "official" way to do that without trusted Client Credentials. Are Assertions supported? Any other ideas?

Assertions: http://tools.ietf.org/html/draft-iet...-assertions-10

In the forum I found only this old thread http://forum.springsource.org/showth...assertion-flow
and I'm not able to find a document listing all the features of this oauth framework.

Thanks

[errigo]

My fault. I've just seen Spring Security SAML extension http://static.springsource.org/sprin...aml/index.html

And relative forum http://forum.springsource.org/forumdisplay.php?86-SAML

I think this is what i was looking for.

[Dave Syer]

I'd be interested to hear more if it is what you are looking for (or even if not). If your client can't be trusted to store a secret where is it going to get the assertion from?

If you have a SAML IDP already that might well be the way to go. If you don't and you are interested in the assertion model anyway there is some basic support for JWT in spring-security-jwt (in the same repo as Spring OAuth right now). It's just JSON/crypto mashing right now, but it would be easy to use as a library for a client and server that want to exchange and verify generic assertions.

[errigo]

Good point. So I think I misunderstood the meaning and usage of assertions suggested by OAuth2.

You are saying that if the client can't store a secret, it neither can store a private key to sign messages and use assertions, right?
So may you explain me why them are suggested for Public Clients? Can they relay only on the "authentication" given by the user?

[Dave Syer]

I didn't see any mention of "public clients" in the ietf draft link your posted. Can you explain what you mean there?

"Public clients" often means "untrusted clients" which fits your use case I think. Generally they are not given very much access to protected resources, or if they are it is only on behalf of a user and with a short access token expiry. If you want to use client credentials grants with an assertion as authentication I'd say you are either talking about a trusted client (in which case maybe a shared secret would have been just fine for simple use) or else you provide the assertion channel purely for consistency with other clients, but you don't allow access to private data.

[errigo]

I'm talking about this classification http://tools.ietf.org/html/rfc6749#section-2.1

public
Clients incapable of maintaining the confidentiality of their
credentials, and incapable of secure client
authentication via any other means.

native application
A native application is a public client installed and executed on
the device used by the resource owner. Protocol data and
credentials are accessible to the resource owner. It is assumed
that any client authentication credentials included in the
application can be extracted. On the other hand, dynamically
issued credentials such as access tokens or refresh tokens can
receive an acceptable level of protection. At a minimum, these
credentials are protected from hostile servers with which the
application may interact. On some platforms, these credentials
might be protected from other applications residing on the same
device.

In my case the Client is an Android app. As you know it could be harmed by rooting that makes you access everything on the phone, including keys used to crypt/sign anything. I've found a solution for my needs (crypt files and communications) but I need to be trusted by the whole protocol (both Authorization and Resource Server) in some way because the key to crypt files is stored on the server and "downloaded" only to crypt/decrypt.
Here you find an use-case very near to mine (without the cryptography problem) http://tools.ietf.org/html/draft-iet...03#section-2.3

My interest in assertions was to use them to authenticate a Client not able to store a secret, but as you let me note, it isn't possible.