Loading ...
Sorry, an error occurred while loading the content.

Experimental OAuth IMAP support from Google

Expand Messages
  • initfounder
    Information on Google s experimental OAuth support for IMAP can be found at this site: http://sites.google.com/site/oauthgoog/Home/oauthimap We are looking
    Message 1 of 7 , Mar 8, 2010
    View Source
    • 0 Attachment
      Information on Google's experimental OAuth support for IMAP can be found at this site:

      http://sites.google.com/site/oauthgoog/Home/oauthimap

      We are looking forward to discussions on how to standardize approaches for using OAuth&WRAP with SASL enabled protocols like IMAP.

      Eric Sachs
      Product Manager, Google Security
    • atom
      Hi Eric, We d be really happy to see a standardized token authentication mechanism for IMAP and other SASL protocols. The current situation where IMAP clients
      Message 2 of 7 , Mar 9, 2010
      View Source
      • 0 Attachment
        Hi Eric,

        We'd be really happy to see a standardized token authentication mechanism for IMAP and other SASL protocols. The current situation where IMAP clients send the user's username/password on every connection has a lot of problems - specifically:

        1) The mail provider's IMAP interface can be exploited for password cracking. This is a huge headache.

        2) There's no way for a user to revoke authorization without changing their password.

        3) Some users may need to go through special flows that requires more than just a password to authenticate. For instance, the user's account could be in a special state where the user may need to answer a security question.

        We at Yahoo think that the XOAUTH SASL mechanism for GMail IMAP and SMTP is interesting and is a step in the right direction. After reading the doc that you posted, I have a few questions:

        1) How is the client supposed to discover the OAuth URLs? In order to do this in a standardized way, it would probably make sense for the IMAP server to return the URLs of the OAuth endpoints.

        2) Are clients required to have consumer keys and consumer secrets? If so, this would probably hurt interoperability if clients had to pre-register with each Mail provider.

        3) What's the 2 legged flow for?

        4) It seems that returning a signature on every request is overkill, and that an Access Token by itself should be enough, especially if SSL is required. Any thoughts on using OAuth WRAP instead?

        5) Is a browser required for the user to authorize? We strongly requiring a browser for the user to authorize is ideal, however we think that some client developers will balk at opening a browser. We'd like to see support for both browser and browser-less flows. It can be up to the Mail provider to determine which flow is to be used.

        Thanks
        Allen Tom
        Architect, Yahoo! Membership



        --- In sasl_oauth@yahoogroups.com, "initfounder" <esachs@...> wrote:
        >
        > Information on Google's experimental OAuth support for IMAP can be found at this site:
        >
        > http://sites.google.com/site/oauthgoog/Home/oauthimap
        >
        > We are looking forward to discussions on how to standardize approaches for using OAuth&WRAP with SASL enabled protocols like IMAP.
        >
        > Eric Sachs
        > Product Manager, Google Security
        >
      • Bill Mills
        We were having a side conversation, I m going to revisit that in the group context and add a few thoughts. ... ... The above is pretty clean, here are some
        Message 3 of 7 , Mar 9, 2010
        View Source
        • 0 Attachment
          We were having a side conversation, I'm going to revisit that in the group context and add a few thoughts.

          --- In sasl_oauth@yahoogroups.com, "initfounder" <esachs@...> wrote:
          ...
          >
          > http://sites.google.com/site/oauthgoog/Home/oauthimap
          >
          > We are looking forward to discussions on how to standardize approaches for using OAuth&WRAP with SASL enabled protocols like IMAP.
          >
          ...
          The above is pretty clean, here are some additions to discuss:

          1) Authenticator discovery -- If we're going to avoid more complexity for the user (and make test servers possible without having to have separate WebFinger configurations) we need discovery information advertised by the server. The way it's proposed in the WRAP mechanism is that the first client response sends the user information and the server responds with the appropriate authenticator information.

          This does create a 4 step sequence, but if pipelining is supported then it doesn't really matter, since the total additional payload is low.

          If we really want to minimize the bytes sent on a 2-legged request we could send back "OK", I'm not sure if a response is truly required here but SASL might need it.

          2) URL specifications -- the proposed URL format is probably not general enough. That is, for 3 legged OAuth

          https://mail.google.com/mail/b/<email address>/imap/
          https://mail.google.com/mail/b/<email address>/smtp/

          and the following format for two-legged OAuth:

          https://mail.google.com/mail/b/<email address>/imap/?xoauth_requestor_id=<url-escaped email address>
          https://mail.google.com/mail/b/<email address>/smtp/?xoauth_requestor_id=<url-escaped email address>

          Is the protocol encoded in the URL really needed? We'll know by what daemon is being connected to anyway, the clients will have to have decided that already.

          If we are going to define our own scheme for this purpose why not define a very simple new one? We can make the user specifier URL for SASL OAuth be something like:

          xoauth://<hostname>/<email address>

          and

          xoauth://<hostname>/<email address>?xoauth_requestor_id=<url-escaped email address>

          3) Why do we need ?xoauth_requestor_id=<url-escaped email address> in the URL?

          Ergards,

          -bill mills
        • Jamie Nicolson (倪志明)
          I m a little confused--are we trying to come up with a modified version of Google s Xoauth spec? I thought for the standard version we were going to focus on
          Message 4 of 7 , Mar 11, 2010
          View Source
          • 0 Attachment
            I'm a little confused--are we trying to come up with a modified version of Google's Xoauth spec? I thought for the standard version we were going to focus on WRAP only, which would make for a very different mechanism, and render most of the points below moot.

            On Tue, Mar 9, 2010 at 22:37, Bill Mills <wmills@...> wrote:
             

            We were having a side conversation, I'm going to revisit that in the group context and add a few thoughts.

            --- In sasl_oauth@yahoogroups.com, "initfounder" <esachs@...> wrote:
            ...
            >
            > http://sites.google.com/site/oauthgoog/Home/oauthimap
            >
            > We are looking forward to discussions on how to standardize approaches for using OAuth&WRAP with SASL enabled protocols like IMAP.
            >
            ...
            The above is pretty clean, here are some additions to discuss:

            1) Authenticator discovery -- If we're going to avoid more complexity for the user (and make test servers possible without having to have separate WebFinger configurations) we need discovery information advertised by the server. The way it's proposed in the WRAP mechanism is that the first client response sends the user information and the server responds with the appropriate authenticator information.

            This does create a 4 step sequence, but if pipelining is supported then it doesn't really matter, since the total additional payload is low.

            If we really want to minimize the bytes sent on a 2-legged request we could send back "OK", I'm not sure if a response is truly required here but SASL might need it.

            2) URL specifications -- the proposed URL format is probably not general enough. That is, for 3 legged OAuth

            https://mail.google.com/mail/b/<email address>/imap/
            https://mail.google.com/mail/b/<email address>/smtp/

            and the following format for two-legged OAuth:

            https://mail.google.com/mail/b/<email address>/imap/?xoauth_requestor_id=<url-escaped email address>
            https://mail.google.com/mail/b/<email address>/smtp/?xoauth_requestor_id=<url-escaped email address>

            Is the protocol encoded in the URL really needed? We'll know by what daemon is being connected to anyway, the clients will have to have decided that already.

            If we are going to define our own scheme for this purpose why not define a very simple new one? We can make the user specifier URL for SASL OAuth be something like:

            xoauth://<hostname>/<email address>

            and

            xoauth://<hostname>/<email address>?xoauth_requestor_id=<url-escaped email address>

            3) Why do we need ?xoauth_requestor_id=<url-escaped email address> in the URL?

            Ergards,

            -bill mills


          • Allen Tom
            Hi Jamie, We’d like to see a standardized implementation of WRAP for IMAP/SMTP (which can also be reused for SASL protocols). The end result is that there
            Message 5 of 7 , Mar 11, 2010
            View Source
            • 0 Attachment
              Re: [sasl_oauth] Re: Experimental OAuth IMAP support from Google Hi Jamie,

              We’d like to see a standardized implementation of WRAP for IMAP/SMTP (which can also be reused for SASL protocols). The end result is that there should be a single spec that Mail providers and client developers can implement.

              In order for this be open, interoperable, and usable, we’ll need to make all the WRAP details (urls, scopes, etc) discoverable.

              If we can also make the IMAP and SMTP configuration discoverable, that would be great, but that’s a secondary goal, as our primary goal is to to have clients access our services using tokens rather than sending the password on every connection.

              We’d prefer clients to pop open a browser for the user to authenticate and authorize (aka OAuth style), but we also need to support an interface for clients to natively ask for the username/password without requiring a browser (using the WRAP username/password profile)

              Allen

              On 3/11/10 10:47 AM, "Jamie Nicolson   (倪志明)" <nicolson@...> wrote:

                 

              I'm a little confused--are we trying to come up with a modified version of Google's Xoauth spec? I thought for the standard version we were going to focus on WRAP only, which would make for a very different mechanism, and render most of the points below moot.

              On Tue, Mar 9, 2010 at 22:37, Bill Mills <wmills@...> wrote:
              ?
               
               
                 

              We were having a side conversation, I'm going to revisit that in the group context and add a few thoughts.

              --- In sasl_oauth@yahoogroups.com <mailto:sasl_oauth%40yahoogroups.com> , "initfounder" <esachs@...> wrote:
              ...
              >
              > http://sites.google.com/site/oauthgoog/Home/oauthimap
              >
              > We are looking forward to discussions on how to standardize approaches for using OAuth&WRAP with SASL enabled protocols like IMAP.
              >
              ...
              The above is pretty clean, here are some additions to discuss:

              1)  Authenticator discovery -- If we're going to avoid more complexity for the user (and make test servers possible without having to have separate WebFinger configurations) we need discovery information advertised by the server.  The way it's proposed in the WRAP mechanism is that the first client response sends the user information and the server responds with the appropriate authenticator information.

              This does create a 4 step sequence, but if pipelining is supported then it doesn't really matter, since the total additional payload is low.  

              If we really want to minimize the bytes sent on a 2-legged request we could send back "OK", I'm not sure if a response is truly required here but SASL might need it.

              2)  URL specifications  -- the proposed URL format is probably not general enough. That is, for 3 legged OAuth

              https://mail.google.com/mail/b/<email address>/imap/
               https://mail.google.com/mail/b/<email address>/smtp/

              and the following format for two-legged OAuth:

              https://mail.google.com/mail/b/<email address>/imap/?xoauth_requestor_id=<url-escaped email address>
               https://mail.google.com/mail/b/<email address>/smtp/?xoauth_requestor_id=<url-escaped email address>

              Is the protocol encoded in the URL really needed?  We'll know by what daemon is being connected to anyway, the clients will have to have decided that already.

              If we are going to define our own scheme for this purpose why not define a very simple new one?  We can make the user specifier URL for SASL OAuth be something like:

              xoauth://<hostname>/<email address>

              and

              xoauth://<hostname>/<email address>?xoauth_requestor_id=<url-escaped email address>

              3)  Why do we need ?xoauth_requestor_id=<url-escaped email address> in the URL?

              Ergards,

              -bill mills

               
                 
               

               
                 


            • William Mills
              We certainly need WRAP supported. There is also value in having OAuth 1.0a supported in a SASL profile, certainly to support 3rd party integrations. That s
              Message 6 of 7 , Mar 11, 2010
              View Source
              • 0 Attachment
                
                We certainly need WRAP supported.
                 
                There is also value in having OAuth 1.0a supported in a SASL profile, certainly to support 3rd party integrations.  That's still a question for discussion.  They are enough different that I think they should have 2 different SASL mechanisms.  I had though it reasonable to discuss both here.
                 
                -bill


                From: sasl_oauth@yahoogroups.com [mailto:sasl_oauth@yahoogroups.com] On Behalf Of Jamie Nicolson (???)
                Sent: Thursday, March 11, 2010 10:48 AM
                To: sasl_oauth@yahoogroups.com
                Subject: Re: [sasl_oauth] Re: Experimental OAuth IMAP support from Google

                 

                I'm a little confused--are we trying to come up with a modified version of Google's Xoauth spec? I thought for the standard version we were going to focus on WRAP only, which would make for a very different mechanism, and render most of the points below moot.

                On Tue, Mar 9, 2010 at 22:37, Bill Mills <wmills@yahoo- inc.com> wrote:

                We were having a side conversation, I'm going to revisit that in the group context and add a few thoughts.

                --- In sasl_oauth@yahoogro ups.com, "initfounder" <esachs@...> wrote:
                ...
                >
                > http://sites. google.com/ site/oauthgoog/ Home/oauthimap
                >
                > We are looking forward to discussions on how to standardize approaches for using OAuth&WRAP with SASL enabled protocols like IMAP.
                >
                ...
                The above is pretty clean, here are some additions to discuss:

                1) Authenticator discovery -- If we're going to avoid more complexity for the user (and make test servers possible without having to have separate WebFinger configurations) we need discovery information advertised by the server. The way it's proposed in the WRAP mechanism is that the first client response sends the user information and the server responds with the appropriate authenticator information.

                This does create a 4 step sequence, but if pipelining is supported then it doesn't really matter, since the total additional payload is low.

                If we really want to minimize the bytes sent on a 2-legged request we could send back "OK", I'm not sure if a response is truly required here but SASL might need it.

                2) URL specifications -- the proposed URL format is probably not general enough. That is, for 3 legged OAuth

                https://mail. google.com/ mail/b/<email address>/imap/
                https://mail. google.com/ mail/b/<email address>/smtp/

                and the following format for two-legged OAuth:

                https://mail. google.com/ mail/b/<email address>/imap/?xoauth_ requestor_ id=<url-escaped email address>
                https://mail. google.com/ mail/b/<email address>/smtp/?xoauth_ requestor_ id=<url-escaped email address>

                Is the protocol encoded in the URL really needed? We'll know by what daemon is being connected to anyway, the clients will have to have decided that already.

                If we are going to define our own scheme for this purpose why not define a very simple new one? We can make the user specifier URL for SASL OAuth be something like:

                xoauth://<hostname>/<email address>

                and

                xoauth://<hostname>/<email address>?xoauth_requestor_ id=<url-escaped email address>

                3) Why do we need ?xoauth_requestor_ id=<url-escaped email address> in the URL?

                Ergards,

                -bill mills


              • Bill Mills
                1) We are clearly pursuing a SASL mechanism for WRAP. 2) I believe we should also have a separate SASL Mechanism defined for OAuth 1.0a. the 2 legged
                Message 7 of 7 , Mar 12, 2010
                View Source
                • 0 Attachment
                  1) We are clearly pursuing a SASL mechanism for WRAP.

                  2) I believe we should also have a separate SASL Mechanism defined for OAuth 1.0a. the "2 legged" OAuth case is still an important one and 1.0a is much more appropriate, WRAP isn't intended for this.

                  Is there a compelling reason to combine these in a singe SASL mechanism?

                  -bill
                Your message has been successfully submitted and would be delivered to recipients shortly.