1. Forum
  2. Usenet
  3. COMP.MAIL.PINE

  • On Xoauth

    From Roderick@21:1/5 to All on Mon Mar 7 08:15:52 2022
    Dear Sirs!

    I have some questions.

    (1) I added /auth=xoauth2 also on the smtp server:

    smtp-server=smtp.gmail.com:587/tls/auth=xoauth2/user=xxx

    Is it OK?

    (2) Can I run multiple instances of alpine in the same computer
    with the same Configuration file (and same same ID and Key)?

    (3) Can I run different instances of alpine on different computers
    with the same Configuration file (and same same ID and Key)?

    (4) ID and Key are saved in the configuration file.
    Where does alpine save the temporary tokens?

    Thanks
    Rodrigo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eduardo Chappa@21:1/5 to Roderick on Mon Mar 7 08:44:34 2022
    On Mon, 7 Mar 2022, Roderick wrote:

    (1) I added /auth=xoauth2 also on the smtp server:

    smtp-server=smtp.gmail.com:587/tls/auth=xoauth2/user=xxx

    Is it OK?

    Dear Rodrigo,

    According to https://alpine.x10host.com/alpine/alpine-info/misc/AuthorizeAlpineGmail.html the best setting is

    smtp-server=smtp.gmail.com/ssl/user=[email protected]/auth=xoauth2

    but the one you mentioned should also work.

    (2) Can I run multiple instances of alpine in the same computer
    with the same Configuration file (and same same ID and Key)?

    Yes. This is the same question as asking if you can login multiple times
    with the same username/password, and since Gmail allows that, then this is allowed too.

    (3) Can I run different instances of alpine on different computers
    with the same Configuration file (and same same ID and Key)?

    Yes. You can use the same client-id and client-secret to login from
    anywhere in the world and from any device that supports XOAUTH2. However,
    each device will get its own refresh token and access token.

    (4) ID and Key are saved in the configuration file.
    Where does alpine save the temporary tokens?

    In the password file, or in a Mac in the keychain, or in Windows in the
    Windows Credentials. There are two things that are saved. A token called
    the refresh token, which is valid for life, and another called the access
    token which only lasts for a small amount of time, an hour typically. Both
    are saved locally in your computer.

    Say you went to sleep, closed Alpine and came back the next day. When you
    open Alpine for the first time Alpine will see that it has been over an
    hour since the access token was generated, so it wil not use it and will
    use the refresh token to get a new access token. With that access token
    alpine will login to your account. Now, if you were to open another
    session, say 15 minutes later, in the same computer, then Alpine would
    notice that the access token is still valid, and would create a new
    session with that access-token and it would not try to get a new
    access-token from the server.

    Does this answer the questions?

    --
    Eduardo
    https://tinyurl.com/yc377wlh (web)
    http://repo.or.cz/alpine.git (Git)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to Eduardo Chappa on Mon Mar 7 20:16:08 2022
    On Mon, 7 Mar 2022, Eduardo Chappa wrote:

    Does this answer the questions?

    Yes. Thanks.

    The reason for the last questios was the tokens. I feared
    intereferences between many instances. Or that running in
    a new computer needs tokens from the old computer. Do I
    need to copy also the passfile, or is the configuration file
    enough?

    Well, soon I will be forced to use xoauth, the experience will tell.

    Rodrigo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eduardo Chappa@21:1/5 to Roderick on Mon Mar 7 21:09:04 2022
    On Mon, 7 Mar 2022, Roderick wrote:


    On Mon, 7 Mar 2022, Eduardo Chappa wrote:

    Does this answer the questions?

    Yes. Thanks.

    The reason for the last questios was the tokens. I feared intereferences between many instances. Or that running in a new computer needs tokens
    from the old computer. Do I need to copy also the passfile, or is the configuration file enough?

    Dear Rodrigo,

    all you need to be able to set up xoauth2 is the client-id and client-secret, so the same .pinerc moved from one computer to another will
    work well. Once you start alpine in different devices with the same configuration (same client-id and client-secret) alpine will help you get
    your own access and refresh tokens for that device.

    My experience is that these tokens are not transferable between
    computers (that is, the tokens know in which computer they live, so the verifying server will cancel your authentication if you transfer the
    tokens - or password file - from one computer to another.)

    In summary: transfer the client-id and client-secret between computers
    and go through the authorization process in each device to get your
    refresh and access tokens, and do not transfer your password file. It
    serves no much purpose.

    --
    Eduardo
    https://tinyurl.com/yc377wlh (web)
    http://repo.or.cz/alpine.git (Git)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to All on Sat Mar 26 17:49:48 2022
    I have just read a little from:

    https://datatracker.ietf.org/doc/html/rfc6749

    I did not found a better explanation of oauth2 on the Web.

    I do recognize some advantages, but they are in the context of how I
    use my Email account not worth of the more complicated authentication.

    Rodrigo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eduardo Chappa@21:1/5 to Roderick on Sun Mar 27 10:16:21 2022
    On Sat, 26 Mar 2022, Roderick wrote:


    I have just read a little from:

    https://datatracker.ietf.org/doc/html/rfc6749

    I did not found a better explanation of oauth2 on the Web.

    I do recognize some advantages, but they are in the context of how I use
    my Email account not worth of the more complicated authentication.

    The "advantage" is seen from the perspective of the service provider. A password allows access to all resources of the provider, xoauth2 allows
    access to those resources that you authorize, not all automatically. In
    theory, this allows you to have different passwords (access tokens) for different services. It increases security from that perspective.

    However, my experience is different. All the services that I use through
    the web keep cookies with my login information, and so if anyone were
    going to take control of my computer they would have access to my account
    until that cookie expires, which it typically a month since it was
    generated. I do not see the point of this. It seems that the gained
    security is completely lost because users do not want to authenticate (or double authenticate) every time they login. I think the theorey is bettern
    than the practice in this case. There are ways to counter attack (say by changing the password of the account) but lots of damage could have been
    done in between the unauthorized access and the realization of the
    hacking. I do not see much point in that. The added security is an
    illusion until you get hacked.

    In particular, I recommend that yo ukeep your password file encrypted and
    use a key to unlock it. That way the only way to get into your account
    will be through Alpine, and no one will be able to steal your refreah
    token and use it to login through Alpine.

    Security is an illusion. Don't fall for it.

    --
    Eduardo
    https://tinyurl.com/yc377wlh (web)
    http://repo.or.cz/alpine.git (Git)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roderick@21:1/5 to Eduardo Chappa on Mon Mar 28 09:33:47 2022
    On Sun, 27 Mar 2022, Eduardo Chappa wrote:

    The "advantage" is seen from the perspective of the service provider. A

    I find interesting the concept of separating authorization from
    authentication, but that is also in frameworks like sasl.

    One gives clients different paswords (access tickets) that are not the
    same password to fully access the data on the service provider, and
    one can revoke some of that passwords without changing the last general password. This means other clients still has the (limited) access.

    This of course makes more sense when the clients are third party
    web plattforms. When we are in complete posession of the client
    (alpine installed in the own personal computer), all this mechanism
    turns to be a disadvantage also regarding security.

    Rodrigo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eduardo Chappa@21:1/5 to Roderick on Mon Mar 28 17:14:22 2022
    On Mon, 28 Mar 2022, Roderick wrote:

    I find interesting the concept of separating authorization from authentication, but that is also in frameworks like sasl.

    One gives clients different paswords (access tickets) that are not the
    same password to fully access the data on the service provider, and one
    can revoke some of that passwords without changing the last general
    password. This means other clients still has the (limited) access.

    This of course makes more sense when the clients are third party web plattforms. When we are in complete posession of the client (alpine
    installed in the own personal computer), all this mechanism turns to be
    a disadvantage also regarding security.

    Rodrigo,

    when I have used passwords for apps, my experience has been that the
    same password applies to the same app regardless of place, so in a way it
    works like a password. Xoauth2 also depends on device. Different devices
    get different passwords, and with a way to generate them, not like those impossible to remember passwords per app that are generated by each
    service that are difficult to carry among devices.

    --
    Eduardo
    https://tinyurl.com/yc377wlh (web)
    http://repo.or.cz/alpine.git (Git)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)