OAuth authentication broken - Ring has migrated to new /oauth/v2 endpoint

[ksand012]

Is there an existing issue for this?

• I have searched the existing issues

Describe The Bug

Summary

As of approximately February 23rd, 2026 around noon PST, all authentication attempts fail with a 406 Not Acceptable from Cloudflare. This affects both initial login and refresh token renewal.

Environment

• ring-client-api: latest
• ring-mqtt HA addon
• Home Assistant OS

Current behavior

All requests to https://oauth.ring.com/oauth/token return:

Status: 406 Not Acceptable
Content-Type: text/plain
Body: 406 Not Acceptable

Root cause

Ring has migrated their OAuth flow to new /oauth/v2 endpoints. Captured via browser HAR, the new flow is:

Step 1: Grab CSRF Token

GET https://oauth.ring.com/oauth/v2/signin

Parse csrf-token from <script id="oauth-args">

Step 2: Sign in

POST https://oauth.ring.com/oauth/v2/signin
Content-Type: application/x-www-form-urlencoded

username=<email>&password=<password>&csrf-token=<token>

Step 3: 2FA verification

POST https://oauth.ring.com/oauth/v2/2fa/verify
Content-Type: application/x-www-form-urlencoded

2fa_code=<code>&csrf-token=<token>&remember_me=false

Step 4: Authorization

GET https://oauth.ring.com/oauth/v2/authorize

Returns a 302 redirect that calls https://ring.com/users/sign_in/end.

Step 5: Callback Code
You receive a https://ring.com/users/sign_in/callback response that contains auth token.

Key differences from old flow

• Endpoint changed from /oauth/token to /oauth/v2/signin
• Content-Type changed from application/json to application/x-www-form-urlencoded
• Now requires a CSRF token obtained from the signin page before authenticating
• Multi-step flow instead of single POST
• The old /oauth/token endpoint now returns 406 for both password grant AND refresh token grant

Impact

• New token generation is completely broken
• Existing refresh token renewal is also broken since it also hits the old endpoint
• All ring-client-api users are affected

To Reproduce

Try using the existing oauth system to login and you will receive an error message.

Expected behavior

The system should let you login, enter your 2FA code, and display an auth token.

Relevant log output

Status: 406
URL: https://oauth.ring.com/oauth/token
Headers: {
  "cf-cache-status": "DYNAMIC",
  "connection": "keep-alive",
  "content-length": "20",
  "content-type": "text/plain; charset=utf-8",
  "server": "cloudflare",
  "x-content-type-options": "nosniff"
}
Body: 406 Not Acceptable

Screenshots

No response

Additional context

No response

OS

Windows

Node.js Version

v24.14.0

NPM Version

v11.9.0

ring-client-api

v14.3.0

Operating System

Windows

[ksand012]

@dgreif @tsightler

[dgreif]

Thanks for bringing this to our attention! The flow you described is the web flow, which requires parsing the HTML to get the CSRF token. I'm sure there are different endpoints used by the apps which are more straightforward JSON.

@tsightler my MITM setup is using a much outdated app at this point. Any chance you have a decent setup to capture the flow from an up-to-date app and see what endpoints we need to use?

[ksand012]

I'm sure there are different endpoints used by the apps which are more straightforward JSON.

I don't know how it was before, but I used HTTP Tool Kit on my Android Ring app for logging in and found it following the same steps by re-directing me to the same endpoints in an embedded browser window.

[tsightler]

@ksand012 Thanks for the report, I'm going to question this part though:

Ring has migrated their OAuth flow to new /oauth/v2 endpoints.

Ring has been using these "new" endpoints for years, it's the web auth flow that support things llike passkeys, etc. However, the Andriod app still has support for legacy auth. In the Ring app, on the login screen, there's the option at the bottom that says something like "Having trouble? Sign in here", and if you click that, you can use the classic in-app auth, which, as far as I can tell, continues to use the same endpoints ring-client-api has always used.

This makes me question whether we need an entirely new auth flow or not, it could be something much more simple such as more strict enforcement of headers or something else.

[tsightler]

As of approximately February 23rd, 2026 around noon PST, all authentication attempts fail with a 406 Not Acceptable from Cloudflare. This affects both initial login and refresh token renewal.

Another point of question, refresh tokens are still generated using the same endpoint regardless of the method used to obtain the initial token, so I don't think this can possible be a global change. I have no probablem generating new tokens or getting refresh tokens using the old endpoints. This entire post seems a bit of AI generated assumptions vs any actual troubleshooting of the issue, can you please verify how you know the above?

The most common issue I've seen with 406 is that users either have mulitple instances of tools from different accounts running, and thus Ring temporarily blocks them, or a token failure causes constant retries and Ring temporarily blocks all auth requests. Usually you can just wait for 24 hours with no requests, and it will work again.

It's possible Ring has tightened requirements on things like headers, etc. we've seen this before, but it doesn't seem to be endpoint related since even the native app still uses both endpoints.

[ksand012]

Hi @tsightler ,

Another point of question, refresh tokens are still generated using the same endpoint regardless of the method used to obtain the initial token, so I don't think this can possible be a global change. I have no probablem generating new tokens or getting refresh tokens using the old endpoints.

Thanks for pointing out the alternate login. I was not aware of that option. That seems to rule out my original theory of oauth being deprecated.

I had originally thought this was more of a global issue because myself and a relative (two separate Ring accounts, two separate HAOS servers, two separate IP addresses/physical locations) are running in to this issue and are unable to come up with a solution. Any time we try going through the Ring MQTT login page on HAOS we get the 406 error. Even generating a token through the ring-client-api returns a 406 error.

The most common issue I've seen with 406 is that users either have mulitple instances of tools from different accounts running, and thus Ring temporarily blocks them, or a token failure causes constant retries and Ring temporarily blocks all auth requests. Usually you can just wait for 24 hours with no requests, and it will work again.

Both of our refresh tokens and Ring MQTT systems stopped working around noon on 2/23/26. I've tried to troubleshoot as best as I can and I'm running out of ideas. I even disabled Ring MQTT, waited 4-5 days, then tried generating a token via cmd line ring-client-api and it still returns a 406 error. :(

This entire post seems a bit of AI generated assumptions vs any actual troubleshooting of the issue, can you please verify how you know the above?

Sorry if my original report comes off robotic. I really did think Ring changed everything and I tried to gather any data I could while I had free time by monitoring traffic and seeing the network flow with Ring.

[tsightler]

@ksand012 Any chance you are not in the US? Whoi is your ISP? I noteice you say your are both using ring-mqtt, but neither of you opened issues there.

Could you try to authentiate using the alterneate method in the app, just to prove that it works and it's not a Ring issue. I've seen a few cases where they;'ve unexpectedly blocked some IPs on their auth servers.

We can definitely work out how to do the web based flow (I've already prototyped a solution) but, based on your description, I don't think it will actually solve the problem because the "flow" you posted only covers the initial auth portion, i.e., the steps needed to get the token. Once the token is acquired, it still must be used to authenticate the app and start a session. When using the web-auth flow, the token is passed back to the Andriod app via a callback page, and then the native app uses that token to authenticate and start a session, by PORTing the token to https://oauth.ring.com/oauth/token.

But you state that, even if you aleady have a token, the auth won't work because posts to this endpoint give a 406. This means that simply changing the way we acquire a token isn't the problem.

[ksand012]

@tsightler I am in the US. AT&T Fiber is my ISP. Relative is using Spectrum as their ISP. I just tried to authenticate through the alt method and it works fine on the android app, but still throws a 406 error when trying to authenticate via the ring-client-api or the Ring MQTT login page. I apologize for not opening an issue on the Ring MQTT repo. When I saw I was having problems getting a token with the ring-client-api I figured it wasn't just an issue exclusive to Ring MQTT.

[tsightler]

@ksand012 Thanks for the additional information. I have some ideas, but since I cannot reproduce, I'll probably need you to test some dev versions of ring-mqtt. Are you OK with that?

[ksand012]

@ksand012 Thanks for the additional information. I have some ideas, but since I cannot reproduce, I'll probably need you to test some dev versions of ring-mqtt. Are you OK with that?

Happy to help wherever I can. Just let me know. :) @tsightler

[tsightler]

If you get a chance, would you please try the current dev version of ring-mqtt? To do this you just need go to the addon configuration and change the "branch" config option from "addon" to "dev", and then restart the addon. If you watch the logs you should see it pull in the latest dev branch and it should show 5.9.3, in the banner during startup. This version is using a custom ring-client-api where I've made a few changes to see if it impacts the behavior you are seeing. I've started with the most obvious potential issue, but perhaps it's something else.

BTW, where is you HAOS system running? Is there any chance it's on some system that is using a VPN? I recently had one user that was insistent they were not using VPN only to eventually find out he was running on a Synology (or some storage system like that) and there was some kind of VPN service running on that host that was routing all traffic through it.

[tsightler]

Digging into this a bit more, one of the very telling things is the log output you posted:

Status: 406
URL: https://oauth.ring.com/oauth/token
Headers: {
  "cf-cache-status": "DYNAMIC",
  "connection": "keep-alive",
  "content-length": "20",
  "content-type": "text/plain; charset=utf-8",
  "server": "cloudflare",
  "x-content-type-options": "nosniff"
}
Body: 406 Not Acceptable

This is not from Ring OAuth servers, this response is directly from Cloudflares Web Application Firewall, it is rejecting you prior to the request even making it to Ring's OAuth servers which means you are being filtered out as a bot/attacker. Cloudflare WAF can be more or less restrictive based on things like IP reputation, etc. It does appear that Ring has added a lot of headers to the requests, and I wonder if WAF is simply enforcing those rules more strictly for you for some reason. We may have to work to make ring-client-api look much more like the official app in it's auth requests.

[ksand012]

@tsightler The dev branch worked! I tested it on both mine and my relative's HAOS and we are back in business!

[tsightler]

Thanks for the test @ksand012, I'm not sure of your patience level, but if you'd have the patience to try a few variations, it might help use determine the minimum change required to make this work.

The only actual change in the dev branch is the use of the full user-agent header that the app is using (with version number) vs the generic, non-versioned used historically. It would be less than idea if we have to constantly rev the version string, but not the end of the world I guess.

That being said, I have the idea that it might be more of a "fuzzy" block, the official Ring app passes something like 12 different headers, while ring-client-api only passes 3. The Cloudflare WAF is a bit interesting in this regard, in it's go/no-go decision it weighs factors such as headers, IP reputation, etc. It could be that we were right on the line before, and this new header I've noticed somehow pushed it just over the line. That might also explain why your IP is blocked, while many others seem to work.