I installed OTK on the api gateway and also exchanged the "OTK Client DB Get" fragment, but when I generate a key from the Developer Portal I can not retrieve a token through the endpoint "https://apihom.amil.com.br/ Auth / oauth / v2 / token ".
I have done some analysis, first in the OTK tables, mainly in the oauth_client_key and portal_apikey table, no key and a secret is added in these tables.
Another verification that I realized is that when I generate the key through the portal the Gateway is triggered through two requests:
- https://apihom.amil.com.br:443/api/keys/generate - https://apihom.amil.com.br:443/api/keys/update
Can you share the error you are receiving? Did you install and verify the OAuth test client works correctly?
Once you integrate with portal the oauth client is managed in the SSG generic_entity table. You should be able to find the client ID and secret here.
Oww Nice, I find the key and secret in this table "generic_entity",
I will send my post here to request the token in come soon
How are you submitting the request and which grant type are you using? From the output I see you did not register a callback URL which will cause problems.
<void property="oauthCallbackUrl"> <string></string> </void>
I suggest adding a callback URL in portal and trying to use a Postman or SoapUI to do your test. The implicit grant type is a simple flow you can try:
OAuth Request Scenarios - CA API Management OAuth Toolkit - 3.5 - CA Technologies Documentation
If this generates any errors please provide them here for review.
Now it worked, but in the page that I am redirected I coded to show the headers and the body of the request, but it does not have what is documented:
status: 200Header:content-type: text/htmlBody:The user-agent will receive a login page. This page will request user credentials and the consent of the user. If the user denies the request the client will receive an error. If the user grants the client it will receive the access_token attached to the redirect_uriNext:The OAuth server will redirect the user-agent back to the client:Header:302Header:Location: the-redirect-uri?state=the-given-state#access_token=an-access_token&expires_in=lifetime-in-seconds&token_type=Bearer&scope=granted-scope&id_token=an-id-token-represented-as-jwt&id_token_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
Connection : keep-aliveAccept : */*Accept-Encoding : gzip, deflate, sdchAccept-Language : pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4Authorization : Basic bDd4eDExNzA3NDIwZWEwNTQ3NmE5MzJjZDJjZDE1ODhhZjA5OmE5ZThmZWQyYzEyZTRmNDc4ZjUxNTJjMDg1NDVlZWI2Host : amldktsp153569User-Agent : Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Unfortunately there is not much to go off of here with just those headers. I will need a bit more detail.
What grant type are you trying to use?
It looks to be something other than implicit as you are base64 encoding the client_id and secret in the auth header (not required for implicit). If you used the implicit grant you should be getting back an access_token in the URL hash fragment of the redirect page after authorizing the request (at /auth/oauth/v2/authorize):
If these headers were generated as part of the redirect I would expect to see the HTTP referrer (referer) header. The 302 redirect is expected as the result of the authorization code grant, implicit grant or id token. Others will not return this response.
I see you opened a support case so it may be best to continue working this through that channel. At very least I would need to know the grant type you are using along with your request endpoint and parameters specified.
I found the problem, when I did found:
Thank you for the feedback, I'm glad to hear it is all working now.