Shot. Intervals.icu is a bit easier because it doesn’t use refresh tokens, only access tokens.
1 Like
Is there a limitation for oAuth access to only be limited to one device at any one time?
When I auth using my ipad, i can upload data. But when I do the same to my (already auth) iPhone. I have to re-auth again to be able to upload data.
I’ve never really delve down deeper why this is the case for intervals, DropBox and Strava seems to work for both devices.
Nothing that I am aware of. Intervals.icu only cares that the correct Bearer token is supplied, not where it is coming from.
I’ll check if the token is the same for both devices then.
Just checked. Seems like the Access Token is different between the ipad and the iphone w/ the same login. Is this expected?
Thanks
Hmm. I just had a look at the code and a new token is generated each time a user auths an app and this replaces whatever token might already exist. I could return the existing token if there is one for the app. I wonder if there are any security implications?
For those trying to use this login flow for mobile apps, storing the client secret within your app is a security vulnerability as the secret can be read from the API calls your app makes during the login process. I have developed an AWS Lambda script to proxy the OAuth calls and keep the client secret secure. If this is useful to anyone in the future it is here: Python OAuth flow for Intervals.icu Lambda · GitHub
1 Like
I’ve noticed this to be a problem too David, I can’t see any problem returning an existing token but I’m no security expert…
If I read it correctly, you’re saying that your app (fitnessFatigue) uses this script that is hosted on AWS Lambda to get the accessTokens back to your app?
eg:
Your App → Call Login → Login page triggers the AWS Lambda script → AWS Lambda script executes and then returns the access token → Your App
Is that the flow?
I just took at look at AWS Lambda, basically you need an account as well as pay some amount of money for this service correct?
You’re storing your access token in the iCloud KeyChain correct? I’m no security expert either, but it’s a lot better than me rolling my own. Plus, now 1 token for all devices seems to work.
Hi, thank for your reply.
Yep, you do need to pay to use AWS, but there is a free tier of one million requests per month…
You’re absolutely right about the login flow. The “Redirect URI” that you provide when you sign up should link to the Lambda script. The code on line 76 links back to your app using [a custom URL].(Apple Developer Documentation)
As you say, the access token is stored in Keychain for security.
1 Like
@david Does this access_token expire eventually? I’m getting 403 after a couple of hours or so. It could be due to testing in different devices multiple times, but wanna be sure
Also, what happens with the access_token if user logins in another device, does the old one expires?
AFAIK, the token is once-off (never had to re-login to get a new one)
Whenever a new login is detected, a new token gets generated and that would be the token that has to be used across all your devices. The old one is discarded.
Intervals.icu only generates 1 single token for all your devices, so in order to be able to access, you need to share this token across all your devices.
On My App, I am using the user’s encrypted keychain. Most of these were discussed in just a few posts above.
1 Like
Thanks for your response, I’ll update my app accordingly then
1 Like
It is as app4g says. I am planning to support multiple access tokens per app soon. That was an oversight on my part.
Coming back to this, is multi access token already supported?
Thanks!
I just implemented that. There can be many access tokens for an athlete linked to an app, once for each time they authorise it. The most recent scopes apply to all access tokens.
3 Likes
Thanks! One more question, is there also a scope for managing my athletes? The use case it’s that coaches will be connecting to intervals.
EDIT: Found it in Swagger, there is a ATHLETES scope, but still doesn’t seem to work.
EDIT2: It seems accessing /athletes seems to work with my own API key but not through the bearer token where I get 403.
Currently oauth tokens grant access to the authorising athlete’s data but not to people they follow or coach. This is by design so someone who follows you can’t auth a 3rd party app which then gains access to your data. I think you need to get each athlete to auth your app and then use the correct token depending on the athlete.
Will this work?
The only (specific) issue to us, it’s that we work with coaches and use there data. Unfortunatly our whole data platform is built around the idea of 1 connection → multiple athletes. This was following the same logic as TrainingPeaks basically, where the coached athletes are also available through the API.
Is there a way to have intervals.icu push new activities for a user to an application?
Alternatively, I could regularly poll the API for new activities. Is there a rate limit in place that would limit this solution?
The rate limiting question is also relevant for the backfill scenario (where users first authorize the application and where the applications needs to process historical activities). Are there any limitations on doing that?