On Xoauth

[Roderick]

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

[Eduardo Chappa]

Post by Roderick
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=***@id.com/auth=xoauth2

but the one you mentioned should also work.

Post by Roderick
(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.

Post by Roderick
(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.

Post by Roderick
(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?

[Roderick]

Post by Eduardo Chappa
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

[Eduardo Chappa]

Post by Roderick

Post by Eduardo Chappa
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.

[Roderick]

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

[Eduardo Chappa]

Post by Roderick
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.

[Roderick]

Post by Eduardo Chappa
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

[Eduardo Chappa]

Post by Roderick
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.