Authentication using ClientID and Secret not working

  • 1
  • Problem
  • Updated 2 weeks ago
Hello, I am currently working on a small side project but I am having trouble even getting the .net api to authenticate correctly. I'm not an admin, but I was given the clientid/clientsecet combination. I've followed the documentation as stated and have explored other solutions across the internet(and this forum) but to no avail.

When sending the authoriation url via a webrequest, I keep getting back the log-in page for some reason. Any thoughts on what I'm doing wrong, or is there an admin setting that isn't toggled?

Thanks!
Photo of William Everman

William Everman

  • 6 Posts
  • 0 Reply Likes
  • frustrated

Posted 2 weeks ago

  • 1
Photo of Dale Smith

Dale Smith, Employee

  • 150 Posts
  • 19 Reply Likes
Hi William,

What grant type are you performing? Are you receiving any error when you are directed back to the login page?

There are a few things that could be happening:

1) If using the authorization code or implicit grant,the redirect url may not match the redirect url configured for the oauth client.
2) We do allow the admin of an account to restrict which applications a user can log in with, and if third party apps are restricted, then login would be forbidden for your client id/secret.

If you could also provide the subdomain you are using and a timeframe this happened, I can try and see if any logs were published for your login attempts.

Thanks,
Dale
Photo of William Everman

William Everman

  • 6 Posts
  • 0 Reply Likes
Hi Dale,

First off, thank you for your quick response.
Using the "code" grant type.
I am using the redirect url that was provided when the clientid/secret was returned to us.
Is that third party app restrictions in the admin settings? Since I can't see the screens, I need to know as much as possible to request a change.
subdomain: coatesfs - I've been trying to authenticate within the lats 1-2 hours.

Thanks,
William
(Edited)
Photo of Dale Smith

Dale Smith, Employee

  • 150 Posts
  • 19 Reply Likes
Hi William,

I do not see anything in our logs indicating the issue. I did look up your account settings and ruled out the disabled third party apps. It looks like that setting allows them to be enabled for your account.

So let's walk through the steps to use the code grant type to see if we can determine what is going on.

So first your app will need to direct the user-agent to the sharefile authorize endpoint:

So you will want to redirect the browser (or do a GET) to:

https://coatesfs.sharefile.com/oauth/authorize?response_type=code&client_id=<yourclientid>&redirect_uri=<url encoded redirect uri>&state=<optional state parameter>

After the user logs in, the browser will be directed to the redirect uri provided and so your application will need to be listening on that url. If you are using an embedded browser inside a native app and just grabbing the query string parameters rather than a deployed cloud based client then your app only needs access to the url in the embedded browser.

The sharefile authorization server will have appended the following to the redirect url:
code=<authcode>&apicp=<api control plane>&appcp=<application control plane>&subdomain=coatesfs&state=<state parameter echoed back>&h=<message authentication code>

Utilizing the parameters, your application would make a back channel call to the following:
POST
https://coatesfs.<apicp>/oauth/token
form url encoded body:
code: <authcode>
grant_type: code
client_id: <your client id>
client_secret: <your client secret>

This will return the access token and refresh token.

Do you know where in this process you're seeing an error?

Dale
Photo of Dale Smith

Dale Smith, Employee

  • 150 Posts
  • 19 Reply Likes
Ah, Yes, the authorization code flow is meant for the user to login and grant access to the application. In this way, the client application does not have access to the user's username/password and only the authorization server does. 

If you already know the user name and password you will be using and you want a more "trusted app" approach, then you will want to use the password grant type. However, I caution, that this approach is not wise from a security perspective. For instance, it either involves the client application storing a user name and password combination or requires the client app to ask the user for their username and password. Both are not suggested for security reasons, and contradicts the purpose of oauth. Generally this is only advised in the case of an entirely backend process running under a "service" account. (Ie a user account created solely for this service and isn't actually used by a real end user)

For this approach instead of directing the browser to the authorize endpoint, you would instead directly call the token endpoint:

POST
https://coatesfs.sharefile.com/oauth/token
form-url-encoded body:
client_id: <your client id>
client_secret: <your client secret>
grant_type: password
username: <username>
password: <password>

This will return the access token and refresh token. You can then make calls to the Sharefile V3 API by adding the Authorization header with a value of

Authorization: Bearer <accesstoken>

Dale
Photo of William Everman

William Everman

  • 6 Posts
  • 0 Reply Likes
This is going to be designed as a fully back-end approach, so you are saying I would for sure need to have the username/password to be able to retrieve a token? If this is the case I will just have to get with the administrators to workout a viable solution.
Photo of Dale Smith

Dale Smith, Employee

  • 150 Posts
  • 19 Reply Likes
Yes, in order to generate an access token, it has to be done under a user context. The client id and secret just identify the app, but cannot generate a token by themselves.
Photo of William Everman

William Everman

  • 6 Posts
  • 0 Reply Likes
That is unfortunate, thank you for the guidance and information. I will discuss this with the admins to see if they want to continue this route.
Photo of William Everman

William Everman

  • 6 Posts
  • 0 Reply Likes
Dale - If you could, can you please remove this thread for me? Thanks.