Announcement Announcement Module
Collapse
No announcement yet.
Client authenitcation Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Client authenitcation

    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

  • #2
    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.

    Comment


    • #3
      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.

      Comment


      • #4
        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?

        Comment


        • #5
          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.

          Comment


          • #6
            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.

            Comment

            Working...
            X