09-26-2016 23:53 - edited 09-26-2016 23:57
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post

09-26-2016 23:53 - edited 09-26-2016 23:57
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Hello,
I'm stuck with developing OAuth authentication for a backend application (no GUI) which would fetch data for certain number of predefined user accounts (user credentials are known in front).
I came up with a following solution.
When user account is set up, user consent is requested for the app through the normal user consent process (through browser).
Next, in order to obtain access token, login form is first called with username/password as a background HTTP POST request. Next, authorize endpoint is called, but cookies are passed on from the first HTTP request. Since users have already given consent, I am able to get authorization code which can be used to obtain access token.
So technically is possible. Also putting aside that login form could change in the future and it is not a part of the WEB API. Is this however a valid way of obtaining access token - meaning is the app going to be banned?
Best regards,
Marko
10-03-2016 16:21
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post



10-03-2016 16:21
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
@marmrk: This approach is something that will break in the future. You should not attempt to enter user credentials in the Fitbit authentication form on behalf of a person. If the accounts do not belong to you, it is also a violation of the Fitbit API Terms of Service.
If you can have people give consent using the normal OAuth 2 Authorization Code Grant flow for a Web server application, why would you need to send people through the flow ever again?
The Authorization Code Grant flow results in an access token and a refresh token. You can use the refresh token to obtain a new access token when the current access token expires (assuming the person has not revoked access to your app).

