Authenticating with Phone number username format

[markhuber]

Thanks for the work on the library. I'm trying to authenticate with a G7 sensor through the Share API. I have active followers, but cannot authenticate with the same credentials that work on uam1.dexcom.com

I've reproduced the AuthenticatePublisherAccount call in Postman and am receiving :

 "Code": "AccountPasswordInvalid",
 "Message": "Publisher account password failed"

The only oddity that I can think of is that I signed up entirely through the mobile app and ended up with a username that is my phone number formatted as +10000000 . Are there known issues authenticating when the account has this format number? I have changed passwords and ensured that it is only alphanumeric.

[gagebenne]

Hi, I've poked around at this a bit, and just cant find a means of logging in via phone number. I'll investigate further how the Dexcom G6 / G7 application behaves to see about supporting this behavior.

I do need to update the README to reflect this, but for now I'd recommend just creating a new account using an email / username. Apologies!

[markhuber]

Thanks. I attempted to inspect http traffic from the phone with burpsuite and a different proxy android app. I can see it's still taking to share2.dexcom.com but I believe because of SSL pinning, every time I route through the proxy the app shows the Follow service shows an Internet outage.

If we can get some info on the basic auth procedure I'd be happy to send a pull.

[markhuber]

Just to follow-up. I confirmed with my next sensor that a completely new account signed up through the web interface using my email works as expected. I can authenticate against the API, get readings back from pydexcom and the thing that started my investigation was getting g-watch app working again.

It's worth noting that as a brand new dexcom user (switched from Abbott FS3), the wizard navigation in the app for a new users defaults you to the phone number path unless you explicitly switch over to email. That likely will increase the frequency of these phone number based usernames. Being new, I'm not sure how long that has been in effect.

I noticed #56 posted this weekend. It's interesting that the username format for the phone numbers also starts with +. Perhaps an expected encoding issue for this character?

[findthebug]

Maybe it is nothing. I did some testing on this phone number issue and at least on the dexcom website i was able get a json with some data on it. There is a property called: "usernameType": "PhoneNumber", which indicates what we are looking for. I did a quick test and passed that as an parameter in the json body but with no luck.

// swift code adapted
let jsonBody: [String: String] = [
        "accountName": user,
        "password": password,
        "usernameType": "PhoneNumber",
        "applicationId": dexcomApplicationlID
    ]

Image left: New account (phone-only) Image right: Old account (email)

[findthebug]

What is also interesting: If you login with phone, dexcom is doing a nice job and displays the proper phone number format for each country selected. e.g. Swiss phone is like 000 000 00 00, which is the proper format. if you change countries you will see a lot of different formats like USA is (000) 000-0000. The Country code itself is not represented in that format. maybe we need so post username like 000 000 00 00 with spaces & - ( ) and the country code with other json prop.

Also i read about dexcom is doing the SMS login since may 2023 and all new user will have this option.

https://www.dexcom.com/en-us/creating-dexcom-account-using-mobile-number

[gagebenne]

After doing a bit of Charles Proxy work, I think I'll need to do some openid authentication. I've been able to authenticate using a phone number using Python, and I think there is a means of getting a session ID for the Share service. Probably won't get around to much the month with the holidays, but perhaps in the new year I'll have a moment to implement this feature.

[bruderjakob12]

I'm very interested in getting that issue resolved. Let me know if you need any support.

[gagebenne]

So, had a moment to explore this further. Here's are some loose notes on the login process using oauth / openid:

First request

First it navigates to a sign in page, with a seemingly random UUID. The body contains username and password, and I have confirmed that this can be a phone number.

DEXCOM_IDENTITY_LOGIN_ENDPOINT = "identity/login"
requests.post(
  DEXCOM_BASE_URL + DEXCOM_IDENTITY_LOGIN_ENDPOINT,
  params = {
    "signin": "...", # random UUID
  }
  data = {
    "username": username,
    "password": password,
    "idsrv.xsrf": "...", # random bytes
  },
)

The response returns a location that is used in the next request, along with a lot of cookies. There is also a client_id that is returned and seems to be constant every time. A state is set, but this is likely an oauth thing?

Location:
https://uam1.dexcom.com/identity/connect/authorize
?client_id = 0b72... # known, static
?redirect_uri = https://uam1.dexcom.com/auth.html
?state = ... # some state

Set-Cookie:
Lots of things

Second request

Now using the main oauth endpoint, the client_id from the last request is used (this is different if logging in via Dexcom app, still static though ffda...).

DEXCOM_AUTHORIZE_ENDPOINT = "identity/connect/authorize"
requests.get(
  DEXCOM_BASE_URL + DEXCOM_AUTHORIZE_ENDPOINT,
  params = {
    "client_id": "0b72...", # from first response header
    "redirect_uri": "https://uam1.dexcom.com/auth.html", # from first response header
    "response_type": "token",
    "scope": "AccountManagement",
    "state": "...", # from first response header
  },
  cookies = {}, # from first response header
)

Seems like we get an access_token, but it's a wimpy 3600 expiration token.

Location: 
https://uam1.dexcom.com/auth.html
?access_token = # random bytes
?token_type = Bearer
?expires_in = 3600
?scope = AccountManagement # same as second request params
?state = ... # same as second request params

Set-Cookie:
Sets cookie idsvr.clients

Third request

Now for the long-lasting token. Another known, static client_id, but this time the oauth scope is openid AccountManagement with response type id_token. The nonce is another field that likely an oauth client could generate.

DEXCOM_AUTHORIZE_ENDPOINT = "identity/connect/authorize"
requests.get(
  DEXCOM_BASE_URL + DEXCOM_AUTHORIZE_ENDPOINT,
  params = {
    "client_id": "1be4...", # known, static
    "redirect_uri": "https://myaccount.dexcom.com/profile",
		"scope": "openid AccountManagement",
		"response_type": "id_token token",
		"nonce" = "...", # random UUID
	},
	cookies = {}, # from first response header
)

Gets back an id_token that is long lasting.

Location:
https://myaccount.dexcom.com/profile
?id_token = # random bytes
?expires_in = 3153600
?session_state = ... # random bytes
?scope = openid AccountManagement

Set-Cookie:
Sets cookie idsvr.clients

Now... I'm hoping I can use this newly found token to retrieve Dexcom Share blood glucose values (or authenticate with the Dexcom Share service), just not sure on how yet.

I have not been able to retrieve this token manually (I was able to perform the first post request as mentioned previously, but that access_token doesn't seem all that useful). I'm just sharing updates to see if there are any oauth folks that have more insight on some of these things.

The SugarPixel by @CustomTypeOne and Gluroo apps are able to authenticate using phone numbers and also utilize the Dexcom Share service, so it's possible.

[dreksten]

Just switched from FSL3 to G7 and can confirm that the default signup is with a phone number, at least in my region (Switzerland), and I'd expect that many (most?) new users of the G7 will end up with phone number IDs as well. It seems ~~Sugarmate~~ (edit: SugarPixel) is also able to connect using the phone number accounts. I'd be glad to help in any way I can.