How to create OAuth2 Opaque(Reference) Access Tokens in apimanager 410? I followed enter link description here, but cannot find OAUTH token type when we create applications.
I want to create this application because of the issue enter link description here. if same token is sent every time we call the token api, this will work for us. Our tests need to get the token first and use it from there. there can be different apis calling in different times and this will expire the first token.
There is a lengthy manual method that lets you to create opaque tokens in APIM 4.1.0, but our recommendation is to proceed with the JWT token-based applications. This will reduce the load at the gateway with token validation which is a huge performance gain. Even if you used the same clientID, or secret Pair, you can change the scopes set with a device scope and I believe this should give you the ability to create multiple tokens at the same time.
Having said that, you can create opaque token in the below approach, but this will remove the user experience provided in the devportal and you have to use carbon console(https://localhost:9443/carbon) if you need to change your application.
log in to admin portal (https://localhost:9443/admin)
Open Key managers --> resident key manager (or whatever the key manager you have) --> and select Out Of Band Provisioning and save.
Log in to carbon console (https://localhost:9443/carabon)
Register a service provider.
Under Inbound authentication config, select OAuth/OpenID connect configurations and configure an OAuth Applicaiton
Add you application details from here as you prefer with the listed grant types and create an application.
Make sure to select the token issuer and default. This is where you select whether the token type is JWT or Opaque.
Once you save it, you can find the client ID secret pair in here.
Log in to devportal (https://localhost:9443/devportal)
Create an application.
Under the production Keys section, now you can see a new option enabled as provide existing OAuth keys.
Add the consumer key secret pair you created in the step 8.
Now you have created an application that generates opaque tokens.
In the latest API Manager versions do not allow generating opaque access tokens. You can use the following configuration to the deployment.toml of API Manager and disable token revocation on token renewal.
[oauth.access_token]
invoke_token_revocation_event_on_renewal = false
Related
I have an API that I have setup in WSO2's API Manager Publisher tool. All the calls work fine when called correctly with an Access Token.
But I have one url that I want anyone to be able to call. (It is a customized Swagger UI page (different from the one built into the WSO2 tooling).)
To do this I add the Swagger UI url as a resource. But when I go there it says:
Required OAuth credentials not provided. Make sure your API invocation call has a header: 'Authorization : Bearer ACCESS_TOKEN'
Generally, I really like this default. (I want all my other API resources to require an Access Token.) But for this one I don't have an access token and don't expect to.)
Is it possible to publish one resource and not need any authentication?
Also it can be done in 2.x versions of API Manager through disabling for each endpoint the security in publisher tool. In manage tab, resources section, for each resource/endpoint set the value x-auth-type to "None". Default value is "Application & Application User". This disable security and then authentication required for accesing to the selected API resources.
This can be done as mentioned in https://stackoverflow.com/a/61133046/3176125
Basically you can turn off for one of the resources while you allow security for the rest of the resources.
I have my web application. Now i want to integrate salesforce into my web app so that i can push data from my app to any salesforce org after the authentication(OAuth).
I found 2 ways:
1. Connected Apps
2. via wsdl generation file and use
I created a connected app from my developer account and i authenticated using consumer key, cusumer secret key(from my connected app) and username of user and secret token of the user account.
I tried with another free trail account, It's validating and fetching the details and post data also working.
My question is, shall i deploy my connected app into app exchange, then only i caan use REST APIs ?
generating wsdl and coding around is the better option than the above ?
Is there a option, only one time authentication enough for any number of sessions and use the REST APIs?
Please suggest me a best way to proceed.
You're mixing up a couple of independent issues here.
If you're going to authenticate via OAuth, you must have a Connected App.
A SOAP API login() call requires you to store a username and password, which is undesirable.
There is no way to "permanently" authenticate, i.e., to get a session id that never expires. Your app must always be ready to get a new access token via the OAuth refresh token it obtains and stores (via, for example, the Web Server OAuth flow), or to reauthenticate via JWT flow.
Connected Apps are global metadata in most cases. You don't need to deploy a Connected App into a target org in order to authenticate using its Client Id and Secret into that org. The only exception I'm aware of is if you want to use the JWT flow with a certificate and preauthorized Profiles and Permission Sets.
Based on what you've shared, I don't see any reason for the AppExchange to be involved.
I have a Django Rest API with JWT authentication which is the backend for a Angular frontend. There are many clients who use the service with our frontend. Now some enterprise clients wanted to integrate the APIs from their system's backend. I don't want to remove JWT from current APIs. I am planning to create new APIs in the same backend with OAuth token for those users.
I wonder what is the best way to implement OAuth for this scenario.
I am thinking Client Credentials grant type is the best way.
Question1: Am I right that client credentials is the right approach ?
For those enterprise users, it is sufficient they get just access token through the UI interface so that they can access all our APIs.
But here the problem is one additional step of getting the Client ID and Client Secret first and using that to get Access Token.
Question 2: What is the use of client ID and client secret ?
Question3: Should my backend hide the process of generating Client ID and Client secret and just give Access token (or) give them Client ID and Client Secret and ask then to generate access token ?
Question 4: If I am giving them Access Token without client id and secret, is that fine to have infinite expiry time? and
TLDR; How to implement OAuth when the resource server and auth servers are same ?
There are 4 grant types in oAuth2 which is meant for different scenarios.
client credential : the consumer (app) make calls to back-end using the bearer token created using apikey(or clientId) and secret only. Mostly used for anonymous calls where generic information is retrieved.
Resource owner password credential (ROPC) : the consumer (app) make calls using the bearer token created using apikey, secret, username and password. Mostly used when you(your authorization server) already know the users(user database is handled in your own system).
Authorization code : the consumer (app) make calls using the bearer token created using an authorization code. The authorization code is provided by a 3rd party (which actually has/manages the logged in user data) and the created authorization code linked to the logged in user. Google and Facebook log in for various sites is a typical example. Facebook/Google gives an authorization code for those websites and they exchange that code for a token.
Implicit grant : Mix of password credential and authorization code. Instead of authorization code, you get a bearer token from the 3rd party authorization server.
Question1: Am I right that client credentials is the right approach ?
I think you can use CC if there is no user level logics in your backend. If userlevel involved, may be ROPC is a better choice
Question 2: What is the use of client ID and client secret ?
Client ID and Client Secret is very similar to username and password in an application level, which is used to obtain bearer token.
Question3: Should my backend hide the process of generating Client ID and Client secret and just give Access token (or) give them Client ID and Client Secret and ask then to generate access token ?
If you are implementing oAuth2, your consumer should create the access token. But looking at your use case, may be even a simple hash of userId+timestamp is sufficient. ;)
Question1: Am I right that client credentials is the right approach ?
Yes. Providing the new APIs do not need to be called in the context of an end user.
Question 2: What is the use of client ID and client secret ?
The client ID allows the auth server to identify the application
requesting the token (it's often carried through to the access token
too, allowing the API to identify the calling application).
The client Secret means the auth server can trust that the client is
genuinely who he says he is as only he should have the private client
secret for his public client ID.
It's effectively a username and password in this scenario.
Question3: Should my backend hide the process of generating Client ID
and Client secret and just give Access token (or) give them Client ID
and Client Secret and ask then to generate access token ?
Your Auth server should issue the client credentials to the application once and the application should provide those credentials every time they wish to obtain a token via the client credentials grant type.
authorization code grant, or implicit grant might be more suitable for this scenario. The first one allows you to add an authentication step before the tokens are returned to the users (might be useful if you want to integrate your JWT authentication to this as well) and the second one is mainly used for single-page applications, and does not include an intermediate authentication step. This one would be useful if you want to improve efficiency.
client_id and client_secret are given to you when you register a client application in your identity provider(authorization server). This client application does not mean an application or an API belonging to your clients, but your own application to which you plan to incorporate OAuth(and OIDC). These two parameters are useful when making the requests to authorization in order to obtain tokens. The server uses those values to determine whether the request is made by a valid application. Only you have access to those values as you will be the one who's registering the application with the server.
I think this question is answered in the previous section.
I think it would be better if you go through this before doing any implementation. It provides most of the basic knowledge you should have before implementing an OAuth system. I hope this answer was useful to you.
I a trying to deploy WSO2 API manager (APIM) with a custom valid certificate and to use the option to encrypt in the DB token and secret user information.
I can use my certificate all right, its green even in chrome and everything will work: token emission, api consomption with a token and token revocation. But, as soon as I try to use the option to encrypt tokens I get an error when trying to use the token. Token expired. If I push the logging to DEBUG level, nothing unusual happens but for the token being considered expired and APIM returns expired credentials.
Any one know how to use this options ? And yes, I have tried to set that option from the get go to make sure is active before any user, api, tenant or anything else is created on the server. If I deactivate it, every thing works normally for subscription taken after deactivation.
Thank you.
I am trying to develop mobile native apps with ionic2 and django rest framework. And I found django-rest-framework-jwt library that support great jwt authentication. However it doesn't refresh token automatically so that users of mobile apps should type their username and password whenver the token expires..
I already checked another stackoverflow question below.
JWT (JSON Web Token) automatic prolongation of expiration
Is there any way that users don't have to type their username and password again? Or Is it ok let token not to be expired and save it local storage of mobile apps so that users don't have to login again?
Thanks in advance!
I've run into the same scenario with our Django and DRF-based projects, and we wanted to implement Single sign-on using JWT. Since the djangorestframework-jwt library had very little focus on providing SSO capabilities between different projects, I have created a new library for this that properly sets up trust definitions and public/private key pairs.
This library provides two types of JWT tokens:
non-expiring session tokens for your primary login application (aka. "refresh tokens")
short-lived authorization tokens for accessing your other apps (these contain permissions given by the primary app)
The client is expected to first login to your primary login application by POSTing an username and password. The client will receive a permanent session token that will allow subsequent requests to the same server be authenticated. These tokens do not contain any permissions/authorization information and cannot be used for SSO into other apps.
Afterwards, the client is expected to obtain and keep updating authorization tokens using the session token. These secondary tokens are short-lived (15mins..1 hour) and contain the permissions that the user has at the time of issuance. These tokens are used to access other services, which then trust the permissions in the JWT payload for the lifetime of the token.
The current version is v0.0.3 (alpha), but we are moving very fast towards a beta and finally production quality release. The API is already relatively stable and should be final by June 30th 2016. The framework will also have full test coverage in the coming weeks, when we reach the beta stage.
Please check the project page and github for the README.
https://pypi.python.org/pypi/djangorestframework-sso
https://github.com/namespace-ee/django-rest-framework-sso
Please let me know if this would fit your use case, and if it has all the features required. I'll be happy to help with the setup.