I have a Java Adapter on my MobileFirst Server. I want to obtain an access token from the server in order to call the Adapter-API functions.
I have successfully done this with Postman using "Basic Auth" by giving Username and password (which I had defined in the MFP console before that) as parameters.
Now I want to get a token by using OAuth 2.0 as Type. How can I do this? I do not see any settings for that in the MFP console
You can access the /token endpoint only with Basic Authentication option. /token endpoint does not support accessing with OAuth token instead of Basic Auth .
The approach you are taking is to access Adapter endpoints from non-MFP SDK methods ( REST clients, Curl etc) .
When using non-MFP SDK clients, you need to execute the steps manually
create a confidential client for the scopes you require
Invoke the /token endpoint to obtain the token - here you will need to pass on Basic Auth to invoke the endpoint and also the scopes you need
Once you have the OAuth token, you will need to manually add the Authorization header to further requests and add the Bearer Token as the value.
if you are new to mobilefirst, and want to refer to sample programs for accessing a protected resource via OAUTH, you can refer samples
For a protected resource access via OAUTH, Please refer to samples https://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.dev.doc/dev/c_oauth_custom_resource_request_samples.html
More securitycheck adapters samples for various user scenarios can be found here https://mobilefirstplatform.ibmcloud.com/tutorials/ru/foundation/8.0/authentication-and-security/
Related
I am having trouble understanding how to accomplish this. I have Firebase functions running on my application. I am using an external API in which I can configure Webhooks to hit an endpoint on my Firebase functions to perform an action. To make sure that the call comes from this external API, they recommend using an oauth2 flow. Mainly they ask me for:
Provide us (the external API) with an ID and an access token;
these are used to access a URL which provides a bearer token;
this bearer token is then used to access the provided webhook URL until the bearer
token expires after a pre-determined period of time.
And there are 4 input fields:
1. OAuth2 access token url
2. OAuth2 client id
3. OAuth client secret
4. OAuth2 Scope. <---- NOT SURE WHAT THIS ONE MEANS
My question is how do I generate the access token and the client id for this external API?
What value should I put for the oAuth2 scope?
Thanks!
I was able to figure this out using auth0. In one of their documentations, they cleared explained what I was trying to accomplish. Posting here to future reference in case any one needs it.
Thanks all!
reference: https://auth0.com/docs/authorization/flows/client-credentials-flow#learn-more
You can generate the client ID and client secret in the Console > Credentials.
Cloud Functions API oAuth2 scope is https://www.googleapis.com/auth/cloud-platform.
I'm learning about the OAuth /introspect endpoint as a means to validate an Access Token. I'm using Okta, which I think is relevant to the question.
I've read online that the /introspect endpoint is intended to be called by an OAuth Resource Server (for example, an OAuth Client would call a Resource Server, providing an Access Token, and the Resource Server would call the /introspect endpoint to make sure the token is valid).
However, the /introspect endpoint (at least with Okta) requires you to provide the OAuth Client credentials (either as a basic auth header, or in the case where there is no client secret, just a client_id request param).
So, how can the Resource Server call the /introspect endpoint when it doesn't have the OAuth Client ID and/or secret? This is making me wonder if the /introspect endpoint is meant to be called by the OAuth Client instead, which to me, doesn't seem as useful.
Please refer to this article. Resource server needs to be a registered client application at Okta and client credentials in /introspect refer to this client's.
Based on my understanding the introspection endpoint is meant to be called by an API resource.
This endpoint is used by the API resource in order to validate the bearer token provided with an incoming HTTP request issued by a client application.
Most of the times this happens when the provided bearer token is a reference token, so the API resource server needs to known whether the provided reference token is associated with a valid access token. This information must be asked to the secure token server via a call to the introspection endpoint.
You can find more information here in the identity server docs. Identity server is a .NET implementation of the openid connect protocol, which is based itsel on oauth2.
This is a documentation that shows you how to call the introspection endpoint programmatically. This documentation is specific for a .NET library called identity model, but this is not relavant for your question, because the library simply implements the protocol.
As you can see in the example of the linked documentation, the client id that you need to specify when you call the introspection endpoint is simply the name of the API resource. The client secret is the API resource secret that you have defined for your API resource.
So, the source of your confusion is simply a terminology overload. In the context of the call to the introspection endpoint both of the following equations hold true:
client id == API resource name
client secret == API resource secret
This docs confirm both of my assumptions.
If it helps here are a few resources of mine, to add to Enrico's answer:
API Setup - see step 6 - you have to register an OAuth Client for the API
API OAuth Messages - see steps 16, 17 and 19 for the three types of response your API needs to deal with
API Code - for an example implementation in NodeJS
I`m new to OAuth 2.0 and am trying to develop a application using a third party OAuth provider with Authorization Code grant flow as ny Authorization Server and Spring Security.
This provider gives me two endpoints /authorize and /token and those two, after the user authorizes its access, will return a access token.
So far, I have secured the "/" endpoint, so the application redirect the user to the authorization page and then, in the callback endpoint, store the token so it can be validated by a filter in each request.
But, as the application is mainly a set of REST API's, we want to be able to test it using Postman, with that said, on Postman, I am getting the token by setting the Authorization as OAuth 2.0 and requesting the token directly from the third party endpoints but, as Postman have its own callback URI, my application doesn`t store the token generated.
So, my two questions on this are:
Using /callback endpoint to store the token and validating it before each request by a filter is the common way of doing it?
To use Postman, should I create an endpoint for storing the token generated outside the application context or should I create an Authorization Server of my own as an additional layer on top of this third party AS?
Since your application is a set of REST API's, you need to make it as a Resource Server (in terms of OAuth2).
Resource Server doesn't perform authentication itself, it only validates a token from Authorization header (Resource Server in a nutshell).
You can find an example in Spring Security samples: oauth2resourceserver
I eventually come to the conclusion that I was using Postman wrong the whole time.
So, by the end, we got the Token saved on the database when the user logs in and, then, return it to the caller, whether it is the Front-end application, or Postman itself.
Then, in every call to the API's, the caller should include the token as Authorization on the header and a Filter on Spring will check the token against the Database.
Generally OAuth definition says that it is way where user gives an application access to his resources stored in other application (without exposing the actual username and password). But inside Owin, it is a way to implement token based authentication within an application. Although we can deploy the Authorisation application at different server. But crux remains the same. Could anybody shed some light. I am very confused.
Thanks in advance
If you take a look at the OAuth 2.0 spec you will find this:
The authorization process utilizes two authorization server
endpoints (HTTP resources):
o Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
o Token endpoint - used by the client to exchange an authorization
grant for an access token, typically with client authentication.
As well as one client endpoint:
o Redirection endpoint - used by the authorization server to
return
responses containing authorization credentials to the client via
the resource owner user-agent.
Not every authorization grant type utilizes both endpoints.
Extension grant types MAY define additional endpoints as needed.
So basically, you have 2 options:
1) Use the authorization endpoint where your end-user is redirected to a form that is handled by the authorization server
OR
2) Create your own form inside your app, get the end-user credentials and send that data to the authorization server, where it will be validated and return a token for you to use.
You can implement the "Authorization Code Flow" in this situation?
A single page app in www.app.com
A REST backend in www.backend.com
Is possible to obtain via javascript an "authorization code" and then pass it to the "backend" for this get the "access token"?
In theory, using the authorization code flow (or the hybrid flow) with a JS/mobile/desktop application is definitely possible, and you don't even need to store client credentials for that (you could, of course, but extracting them is so easy that it would be pointless).
Contrary to popular belief, client authentication is not required for "public" applications (i.e apps that cannot safely store their credentials, which includes JS apps) when using the authorization code flow:
If the client type is confidential or the client was issued client
credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described
in Section 3.2.1.
https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3
f the Client is a Confidential Client, then it MUST authenticate to the Token Endpoint using the authentication method registered for its client_id, as described in Section 9.
http://openid.net/specs/openid-connect-core-1_0.html#TokenRequest
In practice, I'm pretty sure most authorization/authentication servers will enforce client authentication when using the authorization code flow and will instead recommend using the implicit flow for public apps.
If your authorization server supports this scenario, using the authorization code flow in your JS app should be easy if you use response_mode=query (or better: response_mode=fragment as suggested by #Hans), since you can use your JS main page as the redirect_uri and use some JS to extract the authorization code from the query string or from the fragment.
That is possible by setting the redirect_uri to somewhere in your SPA, pickup the code from the authorization response (using any of the methods described in How to get the value from the GET parameters?) and pass it on to the backend in an application specific way. When using OpenID Connect there's the option to have the code delivered in the fragment of the redirect_uri which has some security advantages over having it delivered as a query parameter.