From Newsgroup: comp.mail.pine

Hello,

Unfortunately my university has just blocked the ability to access
Outlook using the Device flow for XOAUTH2. So I need to set up the
Authorize flow.

The Alpine website says that, "The way that Authorize flow works is
similar to the way you would authenticate in Gmail."

Presumably I need to register Alpine as an app in Azure to obtain the
client-id and client-secret? Does anybody have any hints or advice on
how to get Alpine working with the Authorize flow for Outlook?

Thanks very much for any help,

Neil.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On Fri, 12 Jun 2026, Neil wrote:

Unfortunately my university has just blocked the ability to access
Outlook using the Device flow for XOAUTH2. So I need to set up the Authorize flow.

Dear Neil,

I do not have a full answer to your question, so I will tell you what I know and what I don't know.

I am not sure what the reason for the end of support for the Device flow
in Microsoft is. If I knew, I would get you a new one. Device flow is nice
and I still use it with my employer to do authentication for the GRAPH
server. I do not have access to an IMAP server where the Device flow has stopped working.

The last point means that anything I try is just a guess. In order to properly debug this issue I need access to a server where I can reproduce
this and workaround it.

Having said all of this. I am not sure what the situation with other clients is. For example, I do not know what mutt, fetchmail, or others are doing. Reviewing what they are doing will lead you to how to set up the Authorize flow. I know some people are using Thunderbird's client-id and secret. I found this at

https://www.dcs.gla.ac.uk/~jacobd/posts/2022/03/configure-mutt-to-work-with-oauth-20/

Microsoft: client-id - 08162f7c-0fd2-4200-a84a-f25a4db0b584,
client-secret - TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82

However, that might be outdated, since I have heard that some servers do
not recognize this data, as Thunderbird uses a flow that is not
implemented in Alpine.

So, first try to see if the client-id and client-secret above work for
you.

My goal is to understand the underlying issue, so I can properly solve it. Hopefully that will happen soon.

Thank you.
--
Eduardo
https://alpineapp.email (web)
http://repo.or.cz/alpine.git (Git)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine


Dear Eduardo,

Thanks very much for this.

Microsoft: client-id - 08162f7c-0fd2-4200-a84a-f25a4db0b584,
client-secret - TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82

So, first try to see if the client-id and client-secret above work for
you.

I tried using the Thunderbird client-id/client-secret pair given in
your post to access my university email using Outlook with the
Authorize flow. I was able to sign into Microsoft after following the
URL from Alpine, but I then got a text box in my browser asking me to
justify my request and explaining that permission from an
administrator would be needed. I filled in the text box, but have not
heard back from them. I'll let you know if anything happens on this
front.


Meanwhile I have created my own Microsoft account to try to understand
what is needed.


If I set up xoauth2 authorisation (M S U) in Alpine using the
Thunderbird client-id/client-secret pair, i.e.,

Outlook
Client-Id = 08162f7c-0fd2-4200-a84a-f25a4db0b584
Client-Secret = TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82
Tenant = <No Value Set: using "common">
Auth Flow = Authorize
Username = XXX

then I get the message "You can't sign in here with a personal
account. Use your work or school account instead." when I open the URL
offered by Alpine.


I also tried registering Alpine in Azure by going to the "Microsoft
Entra admin center" and clicking on "App registrations". I chose "Any
Entra ID tenant + personal Microsoft accounts" as the supported
account type and a redirect URI of "http://localhost" for "Mobile and
desktop applications". Registering the account gave me the client-id.
I could then click on "Certificates and secrets" and then "New client
secret" to obtain my client-secret. Under "API permissions" I added permissions for IMAP.AccessAsUser.All and SMTP.Send.

When I put the client-id and client-secret in Alpine, I could open the
URL generated by Alpine in my browser, authenticate, and confirm that
I wanted Alpine to access my email. I then got a promising "Unable to
connect" page with URL http://localhost/?code=BLAH%24%24, which I
copied and pasted into Alpine. But Alpine just briefly flashed up a
message

[>Code 400: invalid_grant: AADSTS70000: The provided value for the 'code' parameter is not valid. Trace ID:<]


If I remove the trailing %24%24 from the URL before pasting into
Alpine, I instead get the message

[>Code 400: invalid_request: AADSTS90023: Public clients can't send a client secret. Trace ID: df7ca99c-585b-<]


Have I done anything obviously wrong when registering Alpine?

(I've just discovered that the trailing %24%24 problem can be avoided
by disabling live SDK support in "Authentication (preview) / settings"
when registering Alpine. However, the "Public clients can't send a
client secret" problem persists.)


Thanks again for your help,

Neil.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mail.pine

On Tue, 16 Jun 2026, Neil wrote:

I tried using the Thunderbird client-id/client-secret pair given in
your post to access my university email using Outlook with the
Authorize flow. I was able to sign into Microsoft after following the
URL from Alpine, but I then got a text box in my browser asking me to
justify my request and explaining that permission from an
administrator would be needed. I filled in the text box, but have not
heard back from them. I'll let you know if anything happens on this
front.

The information I quoted is the "old" client-id/secret for Thunderbird. It looks like Thunderbird moved to a "new" client-id without a secret. This
is a different flow that I need to investigate. As as result,
administrators authorize the "new" Thunderbird, and may not authorize the "old" Thunderbird. I hope this makes sense. Chances are you will be asked
to upgrade to a newer Thunderbird.

Meanwhile I have created my own Microsoft account to try to understand
what is needed.

If I set up xoauth2 authorisation (M S U) in Alpine using the
Thunderbird client-id/client-secret pair, i.e.,

Outlook
Client-Id = 08162f7c-0fd2-4200-a84a-f25a4db0b584
Client-Secret = TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82
Tenant = <No Value Set: using "common">
Auth Flow = Authorize
Username = XXX

then I get the message "You can't sign in here with a personal
account. Use your work or school account instead." when I open the URL offered by Alpine.

This error sounds to me like you input "personal@email.com" insted of "school@email.edu" in your username. The other possibility is that
"common" is not what is needed, that the Tenant is different. I am not
sure there is a way to get that (programatically speaking). It needs to be investigated.

I also tried registering Alpine in Azure by going to the "Microsoft
Entra admin center" and clicking on "App registrations". I chose "Any
Entra ID tenant + personal Microsoft accounts" as the supported
account type and a redirect URI of "http://localhost" for "Mobile and
desktop applications". Registering the account gave me the client-id.
I could then click on "Certificates and secrets" and then "New client
secret" to obtain my client-secret. Under "API permissions" I added permissions for IMAP.AccessAsUser.All and SMTP.Send.

This is the full list of permissions Alpine requests:

offline_access https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/SMTP.Send

The first one is so that you can save the access and refresh tokens,
otherwise you will have to do the flow every time.

When I put the client-id and client-secret in Alpine, I could open the
URL generated by Alpine in my browser, authenticate, and confirm that
I wanted Alpine to access my email. I then got a promising "Unable to connect" page with URL http://localhost/?code=BLAH%24%24, which I
copied and pasted into Alpine. But Alpine just briefly flashed up a
message

[>Code 400: invalid_grant: AADSTS70000: The provided value for the 'code' parameter is not valid. Trace ID:<]

If I remove the trailing %24%24 from the URL before pasting into
Alpine, I instead get the message

Code 400: invalid_request: AADSTS90023: Public clients can't send a client secret. Trace ID: df7ca99c-585b-<]

Have I done anything obviously wrong when registering Alpine?

I find your findings very interesting, and worth continue the
investigation. I am thinking that the problem has to do with the way that
the POST request is sent to the server. I am thinking of changing the way
this is done to account for the first error. In regards to the second
error, it seems that the error is to tell you to use a different flow, in other words, only "non-public" clients can use client-secrets, and this
means to implement a different type of flow.

(I've just discovered that the trailing %24%24 problem can be avoided
by disabling live SDK support in "Authentication (preview) / settings"
when registering Alpine. However, the "Public clients can't send a
client secret" problem persists.)

That is a very interesting finding. I need to investigate more about this.

Given that there are 90+ games left in the Football World Cup, I am sure
it will take some time to get there ;).
--
Eduardo
https://alpineapp.email (web)
http://repo.or.cz/alpine.git (Git)
--- Synchronet 3.22a-Linux NewsLink 1.2