Skip to main content

Differentiate generated Access Token & Consumer Key/Consumer Secret in WSO2 APIManager

This blog-post is mainly focus on API subscription process through API-Store  as described in here.
Say there's a hosted WSO2 APIStore instance running in an organization.Once an app developer login to APIStore as an API Subscribe, browse  for available APIs and when he decided to use a set of APIs from his developed external application[eg: mobile/web-based application],he will  add an application to map with his developing app and then he'll subscribe each API to his created application in the APIStore.

When the developer subscribe an API for an application,following three values will be generated on behalf of application.And importantly these three values are generated according to OAuth2 specification.

  • Access Token - 
The OAuth2 token which can be use to authenticate an API invocation.This token is only for the app developer [unless he shared the tokens with others(eg:3rd party users of his developed mobile app)] to use with API invocations from his developed application.[Note he can use above token only with subscribed APIs against the application through APIStore] 
  • Consumer Key  & Consumer Secret - 
The generated consumer key and secret are to use from the client application [developer's app].The usage of these two values is,to authenticate app consumers against underlying consumed APIs from the developed application.For example an application consumer login to the developed mobile app.
Now to continue with app functions [which are exposed through subscribed APIs from the app],the logged app user need to have an access token to use.At this point one option is,app  developer can share his generated application access token with all the app consumers.But this is   not the good approach as it contains some limitations as ,if access token expires,access to the app  will fail among all users,if there's a malicious user as an API consumer,cannot revoke the token only for that user,difficult to differentiate API invocation statistics among API users.Thus best  approach is to keep separate access tokens for each app user.
       
Here the place consumer key and secret are required.These two values are to use with generating user tokens.App developer can hard-coded these two values in his developed app.Then from WSO2 APIManager,we have exposed an REST endpoint to generate such user-tokens with using consumer key/secret as described here. Thus,the app developer  can invoke this endpoint from his developed app and pass consumer key/secret  to the endpoint by adding  the related  implementation to the developed app.

 Hence in summary,only the above generated access token can be directly use to authenticate API invocations,while other consumer key & secret values are to generate such OAuth2 tokens.

Comments

Post a Comment

Popular posts from this blog

Passing end-user details from client to real backend endpoint via JWT token

In real-world business system,WSO2 API Manager useful on exposing company APIs, in a secured and controlled manner with the features provided by APIManager as; OAuth support [To secure API invocations] Throttling support [To control API invocations] Monitoring support [To track API usage] More technically what happening is when a user sends a particular API request,it will goes to WSO2 APIManager node and from there,the request will route to the real implemented back-end endpoint of the particular API and get back the response and returned it to the API invoked user. There can be a use-case,that this back-end endpoint may expect the details of API invoked user as to pass those details to some internal company usage  as; Additional authentication/authorization Track usage data from an internal system. So how to support above requirement from WSO2 AM. There comes the use of JSON Web Token[JWT] implementation done inside WSO2 AM. JWT is a means of representing claims to...
7 comments
Read more

TPP Journey through WSO2 Open Banking

Introduction 2018 is all set to be a game-changing year for European banking. The Revised Payment Services Directive (PSD2) has opened the door to new third party providers [TPPs] to connect with banks and manage finances of bank customers on behalf of them. The PSD2 regulation has mandated banks to expose their core-banking account data and payment services to authorized TPPs to consume. Thus as a bank it’s essential to have a solution which will securely expose their internal banking services to third party providers in a trusted manner. WSO2 Open Banking solution provides all required components to expose bank APIs in a well secured manner in order to become PSD2 compliant. This article explains about the importance of the TPP role in PSD2 domain, the requirements set that banks need to provide for TPPs by PSD2 regulations and how WSO2 Open Banking solution supports these requirements.  From my last blog ,I have given an introduction for PSD2 and WSO2 Open Banking soluti...
4 comments
Read more

How to rollback/commit processing messages from WSO2 ESB when enabled JMS transaction

This blog post describes the below use-case where WSO2 ESB 4.6.0 act as the intermediate channel in-between two JMS queues. The Use-case First messages will be de-queue to a proxy service deployed in WSO2 ESB from an queue in ActiveMQ message broker. Then inside ESB,the incoming messages will undergo with some message mediation flow and then the message will be send to another JMS queue deployed in JBoss server. Inside the ESB,following failures could be happen;            a) Failures during message mediation process failure inside ESB [for example if you                use   dbreportmediator/lookup mediator inside mediation flow,some times failures can                happen due  to database connection failures]          b) Message sending failure,due to endpoint is unavailability.[For example,the JBoss  ...
4 comments
Read more