TRestOAuth and token under basic authentication

[Fredrik Larsson 0]

Hi,

 

I am using TRestOAuth and I am having problems with token.

The first part is getting an accountcode and that works fine.

But then the token couldn't be fetched. 

The server implements a need for basic authentication with clientid:clientsecret to be able to retrieve the token. I guess this is not standard?

Currently I fetch the token manually on the NewCode event and using a httprest component. This of course gives the web page that the account code fetching failed.

 

So any ideas on how to best implement the basic authentication within TRestOAuth?

 

Regards, Fredrik

[Angus Robertson 526]

Unusual, what login data is the required to get the token, something unrelated to OAuth2? 

 

If you want this incorporated in the component, I'd need an end point and account to test it.  Which grant_type are you using?

 

Otherwise you could derive your own version of the component and override the method you are using with your own. 

 

Angus

 

[Fredrik Larsson 0]

54 minutes ago, Angus Robertson said:

Unusual, what login data is the required to get the token, something unrelated to OAuth2? 

 

If you want this incorporated in the component, I'd need an end point and account to test it.  Which grant_type are you using?

 

Otherwise you could derive your own version of the component and override the method you are using with your own. 

 

Angus

 

They use authorization_code

 

They use clientid+clientsecret with basic authentication. At first I thought it was a bit obscure but I read the following from oauth:

https://www.oauth.com/oauth2-servers/access-tokens/authorization-code-request/

 

If the client is authenticating via HTTP Basic Auth or some other method, then this parameter is not required. Otherwise, this parameter is required.

If the client was issued a client secret, then the server must authenticate the client. One way to authenticate the client is to accept another parameter in this request, client_secret. Alternately the authorization server can use HTTP Basic Auth. Technically the spec allows the authorization server to support any form of client authentication, and mentions public/private key pair as an option. In practice, most consumer servers support the simpler methods of authenticating clients using either or both of the methods mentioned here. For more advanced methods of authenticating the client, refer to RFC 7523 which defines a method of using a signed JWT as client authentication.

 

As I understand it, basically a variety of client authentication methods can be used. So perhaps either publishing those properties or have an event where they can be overidden?

It's a bit hard to provide an endpoint for them, since it's a swedish ledger/accounting system and only documentation in Swedish.

 

/Fredrik

[Angus Robertson 526]

OK, seems easy enough, I'll add another TOAOption of OAopAuthBasic and check that in GrantAuthToken to set up basic authentication with the client id and secret.

 

Perhaps you can confirm the endpoint is content to ignore the client stuff as being part of the parameters, safer not to remove them. 

 

I'll send you a unit to test next week, but it's missed the next ICS release.

 

Angus

 

[Fredrik Larsson 0]

That would be perfect. Thanks!

[Angus Robertson 526]

This improvement is now in SVN and the overnight zip, there is a new TOAOption of OAopAuthBasic that causes Basic Authentication to be used instead of sending the client ID and secret as parameters, Microsoft accepts both methods.

 

Angus