I am new to APIGee.
In my project i am using OAuth 2.0 for Authentication.But i am not able to generate the Access Token.
I have created all required policies, but still i am getting the same error all the time.
This is the command i am using to generate the Access Token.
I am using Postman to generate the Access Token.
https://<myorgname>test.apigee.net/<myproxyname>/client_credential/accesstoken?grant_type=client_credentials&client_id=<myclient_id>&client_secret=<myclient_secret>’
I have also tried with curl
https://<myorgname>test.apigee.net/<myproxyname>/client_credential/accesstoken?grant_type=client_credentials -X POST -d 'client_id=<myclient_id>&client_secret=<myclient_secret>’
Both of them give the same error
{
"fault": {
"faultstring": "Classification failed for host orgname-test.apigee.net",
"detail": {
"code": "CLASSIFICATION_FAILED"
}
} }
Please help.
Thanks in advance.
"Classification failed" generally means that the URL is not resolving to any endpoint. There can be several reasons for this:
You are sending in the wrong URL. The URL you need to send in is hostname + basepath + pathsuffix. When you create a proxy in Apigee, by default your basepath will look something like /v1/proxyname. Make sure the /v1 isn't missing. You can also use trace to see what the hostname + basepath is supposed to be.
You are calling https, but your proxy isn't set up for it. Make sure the secure virtual host is referenced in your ProxyEndpoint.
Your HTTP verb may be incorrect. Usually you need to use a POST to get an OAuth token. Make sure your verb matches your implementation. If you don't provide a verb using CURL, it defaults to GET.
Probably not the cause of your error, but the OAuth parameters are generally sent in via a x-www-form-urlencoded payload, not via the command line. Also, the client ID and secret are generally passed in via Basic Auth. Apigee expects these locations by default. See the OAuth 2.0 spec and Apigee's docs for details.
This error usually means the message processors are not able to classify the request - classification error. This can happen due to one of the following:
the proxy is not deployed to the environment that you are hitting
the request host header doesn't match the hostAlias for the environment on which the proxy is deployed.
More details on https://community.apigee.com/questions/13707/unable-to-identify-proxy-for-host.html
Usually the OAuth proxy in APIGEE portal is neither deployed in "Prod" or "Test" initially. We have to manually deploy it to either of the environments to get it working.
Related
Context:
I have a keycloak inside a docker, I understand that there is a "proxy reverse" doing something like transforming this url for example: "http://example.com" into "http://171.20.2.97:8082" (this is the actual place where the Keycloak is "deployed" or "up"). It is just an example, my clients when they need to consume an endpoint from one microservice of mine do not use numbers, they use example.com.
so in the Keycloak when you want to see the metadata of the realm for SAML2.0 you can do it by following this link which is in the REALM settings section:
https://example.com/auth/realms/REALM-NAME/protocol/saml/descriptor
as you can see I am using "example.com" not "171.20.2.97:8082" to access the metadata link.
The problem is that inside the METADATA, the endpoints for SingleSignOnService, SingleLogoutService, etc. Are all configured to be "http://171.20.2.97:8082/auth/realms/REALM-NAME/protocol/saml" (notice it is using the numbers and not example.com) and this causes that when the clients that want to use SAML.
Send inside their SAML REQUEST "Destination" attribute like so: "http://example.com/auth/realms/REALM-NAME/protocol/saml" and this causes an invalid request error, with reason invalid_destination, because the request attribute Destination was expected to be:
"http://171.20.2.97:8082/auth/realms/REALM-NAME/protocol/saml" like is inside the Metadata.
So my question is, how can I edit the metadata to change the endpoints numbers to example.com or if that is not possible, how can I make example.com get translated to 171.20.2.97:8082 inside my keycloak server? Or if you know another way to solve/figure out this it is very welcome
I feel like a BEAST after finding out how to achieve what I needed after like 3 weeks of searching about keycloak and SAML (I overcame many obstacles this was the lastone), finally I managed to fix this by using the "Frontend URL" setting in my REALM settings, there I can put anything I want so that it changes "http://171.20.2.97:8082/auth/" (inside the metadata urls) for whatever I configure there, so for example if I set Frontend URL to:
https://example.com/auth/
now all my metadata endpoints will be like so:
https://example.com/auth/realms/REALM-NAME/protocol/saml
instead of:
http://171.20.2.97:8082/auth/realms/REALM-NAME/protocol/saml
now my client is being able to properly login with SAML2 using keycloak.
how did I manage to find out this? Well there is not much info so this was what gave me the hint: Keycloak behind nginx reverse proxy: SAML Integration invalid_destination
The person asking said that he configured frontend-url, and I wanted to give a try to that, and after checking if that changed metadata urls, surprise it did =)
I am trying to integrate the google-one-tap with my django project on my localhost.
So I added http://localhost:8000 and http://localhost into the Authorized JavaScript origins in Client ID for Web application.
I read some blogs that the above setting does work for the google-one-tap local testing, but it doesn't work for me.
Answer provided here worked for me: The given origin is not allowed for the given client ID (GSI)
As ridiculous as it seems omitting the port and writing http://localhost as JavaScript origin makes the new Google Identity Services code work.
Now my next question is how this change will affect the redirect url, which also accepted a port before.
I finally found out the solution.
It should be set the SECURE_REFERRER_POLICY in the settings.py like this.
SECURE_REFERRER_POLICY = "no-referrer-when-downgrade"
The setup is correct according to the setup instructions here.
Aside from following the above document, please also make sure you are sending the requests from the correct origin. In your case it should be from http://localhost:8000. Please also double check to see if the HTTP headers and parameters in the request also match the authorized origins.
Would you be able to find out which request failed from the web console?
I want to implement Oauth2 protocol from scratch for study purposes.
I'm following the Github guide after having created an App with a Client ID and Client Secret.
The two information sources are pretty simple and are:
https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/
https://gist.github.com/technoweenie/419219
In particular, I'm starting from the first step pasting on my browser:
https://github.com/login/oauth/authorize?client_id=&redirect_uri=http://localhost:8080/auth/temp&scope=user&state=&allow_signup=true
I have a Spring application listening on port 8080 (I don't want to use Spring Security because I want to implement the protocol from scratch) with the following and working endpoint exposed:
#RequestMapping("/auth/temp")
public String redirectAuth(HttpServletRequest request) {
//TODO implement next steps
return "here we are!";
}
but when I go to the github link I get a 404 not found error, as my localhost application wouldn't exist.
I expect the official guide has some mandatory information missing, such as some other endpoints which my application must expose in order to be queried, for instance, about the client secret.
So, what am I missing?
Github only supports the auth code oauth 2 flow. It might be helpful to read up on that.
I have a blog and a video on the auth code flow that may help.
Disclaimer: I work at and created them for Ping Identity, but I think
they'll be helpful even for your study purposes.
https://developer.pingidentity.com/en/blog/posts/2019/what-are-oauth-2-0-grant-types-part-1-authorization-code-flow.html
https://youtu.be/eg7I8x-u0sc
You haven't included your client_id in the authorisation url:
https://github.com/login/oauth/authorize?client_id=&redirect_uri=http://localhost:8080/auth/temp&scope=user&state=&allow_signup=true
The authorization server (GitHub) needs this value to identify the client you have registered.
UPDATE: All calls to the API receive the following response:
failed [500] An error has occurred
Weirdly, my auth process (documented here) works perfectly, while all calls to the API (documented here), fail.
The Bigcommerce API is in transition from basic auth to oAuth. The documentation is consequently a little confusing.
I am trying to create a webhook using the new oAuth methodology. The documentation states that I need an oAuth access_token for the relevant store, which I have obtained.
The documentation also includes sample http request data:
{
"scope": "store/order/*",
"headers": {
"X-Custom-Auth-Header": "{secret_auth_password}"
},
"destination": "https://app.example.com/orders",
"is_active": true
}
In this context, I am assuming that {secret_auth_password} refers to the store's access_token. However, when I include the access_token here I get the following error:
failed [401] You are not authorized.
Thinking that this might be a scoping/permission issue, I have given my app the highest possible level of access through the app settings, but this did not work either.
Thanks in advance for any pointers.
Well after a couple of days of serious head-scratching (not to mention hair out-tearing) I worked out that this was all down to an error in my SSL intermediate certificate, which I have now fixed.
It was the old API returning an error of “UNABLE_TO_VERIFY_LEAF_SIGNATURE” that put me on the right track – the new API just returned:
500 – there is an error
or
404 – you are not authorized.
If you are using PHP I would recommend using the the Webhooks pull request combined with the OAuth pull request. They are both working fine together (I personally use them).
Webhooks pull - https://github.com/bigcommerce/bigcommerce-api-php/pull/101
OAuth pull - https://github.com/bigcommerce/bigcommerce-api-php/pull/88
Then to create a webhook you can just call createWebhook($object)
Object needs to include scope and destination.
Also - a side note.. Are you using SSL for the destination address. It won't work otherwise. You can use a self-signed cert to get around this though.
This will only work for setting up the webhooks though.
To actually receive them you need a valid certificate (else you get nothing).
Hope this helps.
I came across this same part of the documentation and was also confused by it. The proper headers to send for webhooks are the following:
"X-Auth-Client":"[YOUR_APPS_CLIENT_ID]",
"X-Auth-Token":"[OAUTH_ACCESS_TOKEN]"
In addition to using the headers that #FlyingL123 suggested, also take note of of the requirements as noted by BigCommerce:
Requirements
The following properties of the webhooks are required. The request
won’t be fulfilled unless these properties are valid.
scope
destination
I am trying to create an OData model in SAP UI5 this way:
new sap.ui.model.odata.ODataModel("http://services.odata.org/Northwind/Northwind.svc/");
but I am getting a 501 not implemented error!
could you please check what's wrong?
Thanks
As far as I can see it, the service is not really CORS-enabled. I have the same problem with my own examples here, as soon as I am not using some kind of proxy, I get this error.
The reason behind it is that when you send a complex request to the service, you'll autmatically have a so-called preflight request sent by your browser (before the actual GET) which is not a GET-Request, but an HTTP OPTIONS request.
All the odata.org sample services return a 501 error at the moment for such requests.
You can e.g. use the simpleProxyServlet which is shipped with UI5, or of course any other proxy which would solve this.
You are getting this error as your browser will refuse this request due to same Origin Policy. Here is what you should do:
Deploy the app on the same server or domain as the service that you want to call, so that both resources are in the same origin (if possible)
Disable the same-origin policy in the browser for local testing. Run Chrome by running Chrome with the following command:
[your-path-to-chrome-installation-dir]\chrome.exe
--disable-web-security --user-data-dir. Make sure that all instances of Chrome are closed before you run the command. This allows all web
sites to break out of the same-origin policy and connect to the
remote service directly.
-> Don't do this in your productive app as it imposes a security risk.
Using a proxy
The following documentation should help you understand this more and implement:
Conncting with oData Service
Request failing due to Same-Origin Policy sharing(CORS)
Please use "proxy/http/services.odata.org/Northwind/Northwind.svc", I think it's solve your problem!