oAuth2 i.c.m. Multivers / ExactOnline WebAPI in C#/RestSharp

[Massiefje]

Ik ben al sinds vorig week (9 dagen geleden!) bezig om de oAuth2 verificatie van deze API op gang te krijgen. Het is mij 8 dagen geleden 1x gelukt om het werkend te krijgen, waardoor een refreshtoken kreeg en daarmee kan (blijven) werken. Maar de oAuth2 verificatie lukt niet.

In het kort, wat ik doe (zonder code). Ik bouw een URL op aan de hand van de gevraagd info (client_id, redirect_uri, etc) naar de gespecificeerde URL van mijn interne WebAPI website. Ik meld me aan, ik krijg keurig een URL terug in mijn eigen asp.net site met daarin de QueryString code=.

Deze code lees ik uit en stuur ik naar de functie om mijn access_token op te vragen. Je moet hier een string in de body meesturen als plaintext. Ik maak dus eerst een string op en voeg die vervolgens toe aan de body. Deze verstuur ik met een request naar de URL en vervolgens krijg ik constant terug "invalid_request".

Het gekke is, met het refreshen van een token doe ik precies hetzelfde, maar met een andere querystring. De methode (inclusief code) is 100% gelijk aan elkaar. Ik snap dus echt niet wat er fout gaat.

C#:

public IRestResponse getAccessTokenJson(string codeFromURL)
    {
      ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;// | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
      this.codeFromURL = codeFromURL;
      string postURL = endpointAPIUrl + "oauth/token";
      StringBuilder body = new StringBuilder();
      body.Append("code=" + this.codeFromURL);
      body.Append("&client_id=" + API_CLIENT_ID);
      body.Append("&client_secret=" + API_CLIENT_SECRET);
      body.Append("&redirect_uri=" + HttpUtility.UrlEncode(API_REDIRECT_URL).Replace("+", "%20"));
      body.Append("&grant_type=authorization_code");
      string body2 = "code=" + codeFromURL + "?client_id=" + API_CLIENT_ID + "?client_secret=" + API_CLIENT_SECRET + "?redirect_uri=" + API_REDIRECT_URL + "?grant_type=authorization_code";
      var client = new RestClient(postURL);
      var request = new RestRequest();
      request.AddHeader("Content-Type", "application/x-www-form-urlencoded");
      request.RequestFormat = DataFormat.None;
      request.AddParameter("text/plain", body2, ParameterType.RequestBody);
      var response = client.Post(request);
      return response;
    }

Heeft er iemand ervaring met deze API en kan mij vertellen wat ik mis doe of wat er aan de hand is?

Ik controleer overigens op elk moment in mijn C#-code of de code nog wel dezelfde waarde heeft. Dit heeft hij, zelfs als ik een response krijg, staat hij nog goed in de headers verwerkt. Daarom snap ik er niets van.

De client_id en alle overige variabelen komen uit de web.config. Dit is ook getest en worden keurig meegenomen in de request.

Weet niet of het mag *snip* Nee, werving is niet de bedoeling hier Zie daarvoor Devschuurder werven? Gebruik Vraag & Aanbod!

PS: Als ik deze oAuth2 procedure invoer in Postman, werkt het wel. Ook binnen PHP werkt het zonder problemen. Maar het moet in C# werken... En volgens mij kan ik niet zien hoe Postman de oAuth2 opstelt en wat het verschil met mijn headers/body is.

[ Voor 3% gewijzigd door RobIII op 14-02-2022 21:56 ]

[RobIII]

Zo op 't oog: moet je voor body2 niet óók de API_REDIRECT_URL urlencoden? Ik zou sowieso eens goed kijken of je alles wel op de juiste plaatsen encode (en op de juiste manier); in principe met je natuurlijk alle parameters URL-encoden, alleen zal het bij een numerieke code bijvoorbeeld niet heel veel doen.

Verder, op persoonlijke noot: De ExactOnline "API" is een ramp om mee te werken. Ik heb er elke paar maanden ruzie mee Recent mag je "opeens" uit het niks een refresh token weer niet "te vroeg" ophalen....

Do not request a new access token too early
You should only request a new token right before it expires. You can only request a new access token 9 minutes and 30 seconds after you received it. If you request an access token before the 9 minutes and 30 seconds have passed, your call will be rejected with response code 401 and reason Access Token not expired.

Waar dat eerst jaren heeft gewerkt (maar er elke keer wel iets anders begon te zeiken).

[ Voor 88% gewijzigd door RobIII op 14-02-2022 22:05 ]

[Massiefje]

RobIII schreef op maandag 14 februari 2022 @ 21:59:
Zo op 't oog: moet je voor body2 niet óók de API_REDIRECT_URL urlencoden? Ik zou sowieso eens goed kijken of je alles wel op de juiste plaatsen encode (en op de juiste manier).

Ik heb het met en zonder geprobeerd. Beide keren is het resultaat hetzelfde, helaas.

[barellron]

Massiefje schreef op maandag 14 februari 2022 @ 21:53:
PS: Als ik deze oAuth2 procedure invoer in Postman, werkt het wel. Ook binnen PHP werkt het zonder problemen. Maar het moet in C# werken... En volgens mij kan ik niet zien hoe Postman de oAuth2 opstelt en wat het verschil met mijn headers/body is.

Je kan in postman je request exporteren naar C#, misschien zie je dat wat je mist

[Massiefje]

RobIII schreef op maandag 14 februari 2022 @ 21:59:

Verder, op persoonlijke noot: De ExactOnline "API" is een ramp om mee te werken. Ik heb er elke paar maanden ruzie mee Recent mag je "opeens" uit het niks een refresh token weer niet "te vroeg" ophalen....

[...]

Waar dat eerst jaren heeft gewerkt (maar er elke keer wel iets anders begon te zeiken).

Zou dat het niet kunnen zijn? Omdat het refreshen van mijn bestaande token wel werkt? Dat ik gewoon een slechte 'code' terugkrijg, omdat het te snel/laat/vroeg is?

[Massiefje]

barellron schreef op maandag 14 februari 2022 @ 22:12:
[...]


Je kan in postman je request exporteren naar C#, misschien zie je dat wat je mist

Je kan alleen zelf opgebouwde requests exporteren. Niet de standaard 'oAuth2 authentication' die ze voor je doen, zodat je met een werkende access_token je overige requests kan doen.

[RobIII]

Massiefje schreef op maandag 14 februari 2022 @ 22:13:
[...]


Zou dat het niet kunnen zijn? Omdat het refreshen van mijn bestaande token wel werkt? Dat ik gewoon een slechte 'code' terugkrijg, omdat het te snel/laat/vroeg is?

Dat kan zéker; ik ben er zelf ook met vallen en opstaan achter gekomen. I.p.v. een behulpzame melding geeft de Exact "API" op alle fouten gewoon een "invalid_request" terug. Handig joh!

[ Voor 3% gewijzigd door RobIII op 14-02-2022 22:32 ]

[barellron]

Zou je ook niet je parameter met: "application/x-www-form-urlencoded" doen ipv "text/plain", gezien je aangeeft "application/x-www-form-urlencoded" te sturen?

Je kan lijkt mij de variabel body weg doen gezien je die niet gebruikt.
in body2 gebruik je ? als delimiter van de data ipv &

[ Voor 29% gewijzigd door barellron op 14-02-2022 22:34 ]

[Massiefje]

barellron schreef op maandag 14 februari 2022 @ 22:32:
Zou je ook niet je parameter met: "application/x-www-form-urlencoded" doen ipv "text/plain", gezien je aangeeft "application/x-www-form-urlencoded" te sturen?

Je kan lijkt mij de variabel body weg doen gezien je die niet gebruikt.
in body2 gebruik je ? als delimiter van de data ipv &

Helaas, ook geprobeerd. In mijn refreshToken() functie staat hij ook als application/x-www-form-urlencoded. Omdat dat niet (meer?) werkte, had ik dat aangepast naar text/plain, in de hoop dat dat de oplossing was.

Zojuist teruggezet en helaas: invalid_request

body2 had inderdaad een fout. Had ? ipv & gebruikt. In refreshtoken() gebruik ik body met de stringbuilder en dat werkt prima. Dus wilde voor deze een andere optie proberen.

Huidige code met alle aanpassingen, welke dus nog niet werkt:

C#:

public IRestResponse getAccessTokenJson(string codeFromURL)
    {
      ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;// | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
      this.codeFromURL = codeFromURL;
      string postURL = endpointAPIUrl + "oauth/token";
      StringBuilder body = new StringBuilder();
      body.Append("code=" + codeFromURL);
      body.Append("&client_id=" + API_CLIENT_ID);
      body.Append("&client_secret=" + API_CLIENT_SECRET);
      body.Append("&redirect_uri=" + HttpUtility.UrlEncode(API_REDIRECT_URL).Replace("+", "%20"));
      body.Append("&grant_type=authorization_code");
      string body2 = "code=" + codeFromURL + "&client_id=" + API_CLIENT_ID + "&client_secret=" + API_CLIENT_SECRET + "&redirect_uri=" + HttpUtility.UrlEncode(API_REDIRECT_URL).Replace("+", "%20") + "&grant_type=authorization_code";
      var client = new RestClient(postURL);
      var request = new RestRequest();
      request.Method = Method.POST;
      request.AddHeader("Content-Type", "application/x-www-form-urlencoded");
      request.RequestFormat = DataFormat.None;
      request.AddParameter("text/plain", body, ParameterType.RequestBody);
      var response = client.Execute(request);
      return response;
    }

[BertS]

Wat me opvalt is dat je postURL naar oauth/token gaat, en niet naar oauth2/token. Is dat niet de simpele reden?

[Massiefje]

BertS schreef op dinsdag 15 februari 2022 @ 11:34:
Wat me opvalt is dat je postURL naar oauth/token gaat, en niet naar oauth2/token. Is dat niet de simpele reden?

Goede opmerking en ik wist bijna zeker dat het goed stond, maar toch even nagekeken.

In mijn refreshToken() method gebruik ik ook oauth/token en in de documentatie staat dit:

Exchange Authorization Code for an Access Token
In your Web Server Applications you have to read the authorization code from the Redirect URL and exchange it for an access token. You have to make a HTTP POST to the following URL: https://{url}/OAuth/Token

Capitals en lowercase heb ik overigens ook getest en uitgesloten. Helaas is dat het ook niet!

Maar oauth/token is dus correct, gelukkig! Thanks voor het meedenken!

[BertS]

Dat verrast me wel. Op Exact gebruik ik voor een Refresh dit:

code:

var client = new RestClient(new Uri($"{ServerAddress}/oauth2/token"));
var request = new RestRequest(Method.POST);
request.AddHeader("cache-control", "no-cache");
request.AddHeader("content-type", "application/x-www-form-urlencoded");
request.AddParameter("application/x-www-form-urlencoded",
                     $"grant_type=refresh_token&client_id={ClientIdentifier}&client_secret={ClientSecret}&refresh_token={authorization.RefreshToken}",
                     ParameterType.RequestBody);

var response = client.Execute(request);

Edit:
Voor het verkrijgen van een eerste token roep ik deze url aan:

code:

$"{ServerAddress}/oauth2/auth?client_id={ClientIdentifier}&redirect_uri={CallbackUrl}&response_type=code&force_login=1"

Op de callback daarvan lees ik de code-parameter uit (codePart), en vraag dan de rest uit:

code:

var authorizationCode = codePart.Split('=')[1];

var client = new RestClient(new Uri($"{ServerAddress}/oauth2/token"));
var request = new RestRequest(Method.POST);
request.AddHeader("content-type", "application/x-www-form-urlencoded");
request.AddParameter("application/x-www-form-urlencoded",
                        $"code={authorizationCode}&redirect_uri={CallbackUrl}&grant_type=authorization_code&client_id={ClientIdentifier}&client_secret={ClientSecret}",
                        ParameterType.RequestBody);
var response = client.Execute<dynamic>(request);
var data = (Dictionary<string, object>)response.Data;

Het AccessToken gebruik ik vervolgens om mijn acties uit te voeren.

[ Voor 45% gewijzigd door BertS op 15-02-2022 12:03 ]

[Sito]

RobIII schreef op maandag 14 februari 2022 @ 22:32:
[...]

Dat kan zéker; ik ben er zelf ook met vallen en opstaan achter gekomen. I.p.v. een behulpzame melding geeft de Exact "API" op alle fouten gewoon een "invalid_request" terug. Handig joh!

Er zou een straf moeten staan op het bouwen van publieke API's zonder fatsoenlijke error message of documentaties. Sommige partijen zijn daar bar slecht in, zelfs als de API (net zoals in dit geval) door een groot publiek gebruikt wordt.

[Massiefje]

BertS schreef op dinsdag 15 februari 2022 @ 11:58:
Dat verrast me wel. Op Exact gebruik ik voor een Refresh dit:

code:

var client = new RestClient(new Uri($"{ServerAddress}/oauth2/token"));
var request = new RestRequest(Method.POST);
request.AddHeader("cache-control", "no-cache");
request.AddHeader("content-type", "application/x-www-form-urlencoded");
request.AddParameter("application/x-www-form-urlencoded",
                     $"grant_type=refresh_token&client_id={ClientIdentifier}&client_secret={ClientSecret}&refresh_token={authorization.RefreshToken}",
                     ParameterType.RequestBody);

var response = client.Execute(request);

Edit:
Voor het verkrijgen van een eerste token roep ik deze url aan:

code:

$"{ServerAddress}/oauth2/auth?client_id={ClientIdentifier}&redirect_uri={CallbackUrl}&response_type=code&force_login=1"

Op de callback daarvan lees ik de code-parameter uit (codePart), en vraag dan de rest uit:

code:

var authorizationCode = codePart.Split('=')[1];

var client = new RestClient(new Uri($"{ServerAddress}/oauth2/token"));
var request = new RestRequest(Method.POST);
request.AddHeader("content-type", "application/x-www-form-urlencoded");
request.AddParameter("application/x-www-form-urlencoded",
                        $"code={authorizationCode}&redirect_uri={CallbackUrl}&grant_type=authorization_code&client_id={ClientIdentifier}&client_secret={ClientSecret}",
                        ParameterType.RequestBody);
var response = client.Execute<dynamic>(request);
var data = (Dictionary<string, object>)response.Data;

Het AccessToken gebruik ik vervolgens om mijn acties uit te voeren.

Okay, dat is op zich precies hetzelfde als wat ik doe. Alleen jij bouwt je string daar op en ik bouw hem vooraf op. Mag ik vragen hoe de stap ervoor eruit ziet? Dus het opvragen van je eerste access_token?

[Voutloos]

RobIII schreef op maandag 14 februari 2022 @ 21:59:
Waar dat eerst jaren heeft gewerkt (maar er elke keer wel iets anders begon te zeiken).

offtopic:
Checkerdecheck check, dit t-shirt heb ik ook.
Rate limiting op excessive behavior is dikke prima, maar de defaults limits en dit soort extra condities verschuiven het te ver naar de client.

Wij integreren met hun (en tig andere hrm of finance pakketten) én zijn zelf api-first. Naar aanleiding van hun documentatie heb ik wel eens de technische gedachte gehad “o, wat zou het fijn zijn als alle clients netjes gedroegen”, maar no way dat ik ooit voor dit soort vijandige implementaties (die ook nog eens documentatie en supportdruk opleveren) zou kiezen.

[BertS]

Massiefje schreef op dinsdag 15 februari 2022 @ 12:26:
[...]


Okay, dat is op zich precies hetzelfde als wat ik doe. Alleen jij bouwt je string daar op en ik bouw hem vooraf op. Mag ik vragen hoe de stap ervoor eruit ziet? Dus het opvragen van je eerste access_token?

Dat heb ik in het tweede deel van m'n post staan?
Bij mij is het een WinForms-applicatie, waarin ik een Browsercontrol heb. Daarin navigeer ik naar

code:

$"{ServerAddress}/oauth2/auth?client_id={ClientIdentifier}&redirect_uri={CallbackUrl}&response_type=code&force_login=1"

De callback (naar CallbackUrl) vang ik af. Die heeft een queryparameter 'code', waar ik de bijbehorende waarde dus van pak. Die geef ik vervolgens mee in het laatste blok code dat ik hierboven postte (de codePart).

Het verschil zit in de parameters (grant_type/code/refresh_token) die meegaan in de application/x-www-form-urlencoded.

[Massiefje]

BertS schreef op dinsdag 15 februari 2022 @ 12:53:
[...]

Dat heb ik in het tweede deel van m'n post staan?
Bij mij is het een WinForms-applicatie, waarin ik een Browsercontrol heb. Daarin navigeer ik naar

code:

$"{ServerAddress}/oauth2/auth?client_id={ClientIdentifier}&redirect_uri={CallbackUrl}&response_type=code&force_login=1"

De callback (naar CallbackUrl) vang ik af. Die heeft een queryparameter 'code', waar ik de bijbehorende waarde dus van pak. Die geef ik vervolgens mee in het laatste blok code dat ik hierboven postte (de codePart).

Het verschil zit in de parameters (grant_type/code/refresh_token) die meegaan in de application/x-www-form-urlencoded.

Sorry, toen ik op je reageerde stond de rest er nog niet bij!

Ik ga deze code straks ook proberen. Lijkt heel erg op de mijne, maar wellicht zie ik toch iets over het hoofd.

Thanks!

[BertS]

Geen probleem hoor, alleen stond mijn aanvulling wel in jouw quote, dus ik veronderstelde dat je het had gezien.

Grootste kanshebber is m.i. toch die oauth vs oauth2 in de url, maar wellicht kom je nog meer verschillen tegen. Bij mij werkt het in elk geval prima, heb er geen noemenswaardige problemen mee ondervonden bij verschillende gebruikers.

[Massiefje]

BertS schreef op dinsdag 15 februari 2022 @ 13:35:
Geen probleem hoor, alleen stond mijn aanvulling wel in jouw quote, dus ik veronderstelde dat je het had gezien.

Grootste kanshebber is m.i. toch die oauth vs oauth2 in de url, maar wellicht kom je nog meer verschillen tegen. Bij mij werkt het in elk geval prima, heb er geen noemenswaardige problemen mee ondervonden bij verschillende gebruikers.

Helaas, zojuist getest. Het moet bij mij sowieso oauth/token zijn i.p.v. oauth2/token. Die laatste had ik laten staan en daar kreeg ik 'resource not found', oftewel een 404-error op.

Toen ik die aangepast had, werkte het proces precies zoals in mijn code met, helaas, dezelfde uitkomt: error, invalid request.

Ik begin echt te vermoeden dat de eerste stap een probleem geeft: de code die ik terugkrijg is niet okay en daardoor werkt het authenticeren niet.

[Massiefje]

En ik heb zojuist ook jouw URL gebruikt om een code te bemachtigen: helaas werkt dat ook niet.

[RobIII]

Even voor de zekerheid: je doet dus (nu, tijdens het testen) telkens éérst een authorization token ophalen en dan gebruik je die voor een refresh token die je vervolgen (niet te vroeg (en niet te laat)) refreshed?

Want eens je een fout op die refresh token krijgt kun je opnieuw beginnen volgens mij.

[BertS]

Massiefje schreef op dinsdag 15 februari 2022 @ 15:24:
[...]


Helaas, zojuist getest. Het moet bij mij sowieso oauth/token zijn i.p.v. oauth2/token. Die laatste had ik laten staan en daar kreeg ik 'resource not found', oftewel een 404-error op.

Toen ik die aangepast had, werkte het proces precies zoals in mijn code met, helaas, dezelfde uitkomt: error, invalid request.

Ik begin echt te vermoeden dat de eerste stap een probleem geeft: de code die ik terugkrijg is niet okay en daardoor werkt het authenticeren niet.

Wat gebruik je dan als serveraddress? Ik gebruik https://start.exactonline.nl/ (met daarachter dus de oauth2/...)

[Massiefje]

Ik heb zojuist contact gehad met Exact/Unit4. We zijn een paar stappen dichterbij!

Het probleem lijkt in de redirect_uri te zitten. Mijn app maakt gebruik van IISExpress via Visual Studio en die draait op poort 44385. De redirect_uri wordt dan: https://localhost:44385.

Unit4 had een testtool en zodra we deze uri erin gebruikten konden we het probleem repliceren. Echter, zodra we de poort weglieten, werkte het!

Een collega programmeur gebruik PHP voor zijn communicatie met de WebAPI en ook over een andere poort (poort 9999). Daar werkt het wel. Dus de API snapt poorten wel. Dan denk ik dat het iets met URL decoding te maken heeft.

Ik heb vandaag van alles geprobeerd om het op te lossen, maar het enige wat wilde werken was de dev-site op een IIS-server te zetten met z'n eigen hostname op gewoon poort 80. Ik kreeg IISExpress niet op een eigen hostname of op een normale poort die geslikt werd door de API.

Maar het probleem was dus in de redirect_uri!

Thanks voor het helpen allemaal! Maar ik denk dat ik de slagroomtaart zelf maar opeet

[RobIII]

Massiefje schreef op dinsdag 15 februari 2022 @ 21:13:
Een collega programmeur gebruik PHP voor zijn communicatie met de WebAPI en ook over een andere poort (poort 9999). Daar werkt het wel. Dus de API snapt poorten wel. Dan denk ik dat het iets met URL decoding te maken heeft.

Als 9999 wel werkt dan verwacht ik eerder een gare regex ofzo die 1-4 digits slikt voor 't poortnummer (m.a.w. poorten < 10.000).

Massiefje schreef op dinsdag 15 februari 2022 @ 21:13:
Thanks voor het helpen allemaal! Maar ik denk dat ik de slagroomtaart zelf maar opeet

Als het inderdaad de urlencoding is dan is 'ie voor mij Dat was létterlijk de eerste suggestie in 't topic.

[ Voor 3% gewijzigd door RobIII op 15-02-2022 21:23 ]

[Massiefje]

RobIII schreef op dinsdag 15 februari 2022 @ 21:22:
[...]

Als 9999 wel werkt dan verwacht ik eerder een gare regex ofzo die 1-4 digits slikt voor 't poortnummer (m.a.w. poorten < 10.000).


[...]


Als het inderdaad de urlencoding is dan is 'ie voor mij Dat was létterlijk de eerste suggestie in 't topic.

Helaas, het was niet de encoding, maar de manier waarop de URI was samengesteld, blijkbaar. Ik doe nu dit:

C#:

var uri = new Uri(HttpContext.Current.Request.Url.AbsoluteUri);
      var builder = new UriBuilder(HttpContext.Current.Request.Url.Scheme, HttpContext.Current.Request.Url.Host, HttpContext.Current.Request.Url.Port);
      API_REDIRECT_URL = UrlEncode(builder.ToString());

En gek genoeg wordt dat nu wel geslikt....

[RobIII]

Massiefje schreef op maandag 14 februari 2022 @ 21:53:

C#:

string body2 = "code=" + codeFromURL
  + "?client_id=" + API_CLIENT_ID
  + "?client_secret=" + API_CLIENT_SECRE
  + "?redirect_uri=" + API_REDIRECT_URL
  + "?grant_type=authorization_code";

_{Enters toegevoegd voor leesbaarheid}

^^ Hier doe je géén url-encoding van API_REDIRECT_URL

Massiefje schreef op dinsdag 15 februari 2022 @ 22:10:

C#:

API_REDIRECT_URL = UrlEncode(builder.ToString());

^^ En hier wel.

Maar goed, ik zal wel simpel zijn.

Die taart zal me overigens worst wezen. De strekking is nog steeds dat je eerst je url-encoding (blijkbaar) niet goed deed en nu wel als dat "gek genoeg" nu wel opeens wordt "geslikt" .

Edit: Oh Ik zie nu ook dat je overal ? ipv ? en vervolgens & gebruikt(e) daar.
Edit2: Nevermind, dat was al gezegd.

[ Voor 28% gewijzigd door RobIII op 15-02-2022 22:47 ]

[Massiefje]

Ik heb verschillende soorten encoding geprobeerd, zelfs zonder encoding. Het werkte allemaal niet.

Pas toen ik de redirect_uri handmatig ging invullen (en daarna dus de reeds gebruikte encoding weer toepaste), toen werkte het.

Toen wist ik dat het in de string van de URL moest zitten. En ondanks dat het erop leek dat alles wel goed was, was de manier waarop ik het nu deed de enige manier waarop het werkte.

Het werkt nog steeds overigens

Ik denk zelf dat het een 'bugje' in de API zelf is, want medewerkers van Exact/Unit4 konden het fout zien gaan, maar geen verklaring voor geven.