Skip to main content

Generate JWT access tokens from WSO2 Identity Server

In Identity Server 5.2.0 we have created an interface to generate access tokens. Using that we have developed a sample to generate JWT tokens. You can find that sample under msf4j samples[1][2]. If you are build it as it is you will need to use Java 8 to build since msf4j is developed on Java 8. So you will need to run Identity Server on Java 8 as well. After building the project[2] please copy the jar inside target directory to $IS_HOME/repository/components/dropins/ directory. And then please add the following configuration to Identity.xml which is placed under $IS_HOME/repository/conf/identity/ folder inside tag OAuth.

 <IdentityOAuthTokenGenerator>com.wso2.jwt.token.builder.JWTAccessTokenBuilder</IdentityOAuthTokenGenerator>


Then go to the database you used to store oauth tokens (This is the database pointed from the datasource you mentioned in the $IS_HOME/repository/conf/identity/identity.xml) and then alter the size of the column ACCESS_TOKEN of the table IDN_OAUTH2_ACCESS_TOKEN to the maximum value provided by your database provider.


Labels:

Comments

  1. UnknownDecember 10, 2016 at 9:02 PM

    hello, danushka,
    I am following your instruction of confgiuring the WSO2 IS to output Access Token of JWT format.

    I am just using the default embedded H2 database shipped together with WSO2 IS 5.2.0.
    I changed the maximum length of "ACCESS_TOKEN" to 65536 in /dbscripts/identity/h2.sql.

    and restart the IS.

    yet when I called the IS with Oathu2 resource owner password grant type. I still got the following error

    org.h2.jdbc.JdbcSQLException: Value too long for column "ACCESS_TOKEN VARCHAR(255)": "'eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0Ojk0NDNcL29hdXRoMlwvdG9rZW4iLCJzdWIiOiJ3ZW5AY2FyYm9uLnN1cGVyIiwiYXVkIj... (439)"; SQL statement:
    INSERT INTO IDN_OAUTH2_ACCESS_TOKEN (ACCESS_TOKEN, REFRESH_TOKEN, CONSUMER_KEY_ID, AUTHZ_USER, TENANT_ID, USER_DOMAIN, TIME_CREATED, REFRESH_TOKEN_TIME_CREATED, VALIDITY_PERIOD, REFRESH_TOKEN_VALIDITY_PERIOD, TOKEN_SCOPE_HASH, TOKEN_STATE, USER_TYPE, TOKEN_ID, GRANT_TYPE, SUBJECT_IDENTIFIER) SELECT ?,?,ID,?,?,?,?,?,?,?,?,?,?,?,?,? FROM IDN_OAUTH_CONSUMER_APPS WHERE CONSUMER_KEY=? [22001-175]


    it seems that the field length of ACCESS_TOKEN is still 255 instead of 65536.

    so, how do you make the change on H2 database data schema to take effect.


    ReplyDelete
    Replies
    1. AnonymousMay 10, 2017 at 6:22 AM

      Hi George
      You can change h2.sql files in dbscripts folder and then restart the server with -Dsetup.

      Delete
  2. UnknownDecember 13, 2016 at 1:08 AM

    hello, danushka:

    One more question: how do you configure the claims in the JWT Access Token?

    I am using the SCIM interface for provisioning, I intent to have the scimId (urn:scim:schemas:core:1.0:id; UUID generated automatically upon user-generation) to replace userId(userName) in JWT Access Token so that no user privacy is ever compromised. can you please provide a detailed instruction?

    thanks

    ReplyDelete
    Replies
    1. AnonymousMay 10, 2017 at 10:51 PM

      In custom code provided, you can change following line
      https://github.com/wso2/msf4j/blob/master/samples/jwt-claims/JWTAccessTokenBuilder/src/main/java/com/wso2/jwt/token/builder/JWTAccessTokenBuilder.java#L146

      Delete
  3. UnknownApril 12, 2018 at 5:15 AM

    Has your bundle ever been tested in WSO2 IS 5.3.0 ?

    ReplyDelete
    Replies
    1. Danushka FernandoMay 4, 2018 at 12:12 AM

      This is created for IS 5.2.0. Not sure whether it is tested for 5.3.0. Are you having any issues with 5.3.0?

      Delete

Post a Comment

Popular posts from this blog

Setting up Single node Kubernetes Cluster with Core OS bare metal

You might know already there is an official documentation to follow to setup a Kubernetes cluster on Core OS bare metal. But when do that specially single node cluster, I found some gaps in that documentation [1] . And another reason for this blog post is to get everything into one place. So this blog post will describe how to overcome the issues of setting up a single node cluster. Installing Core OS bare metal. You can refer to doc [2]  to install core os.  First thing is about users. Documentation [2]  tells you how to create a user without password. To login as that user you will need ssh keys. So to create a user with username password, you can use a cloud-config.yaml file. Here is a sample. #cloud-config users: - name: user passwd: $6$SALT$3MUMz4cNIRjQ/Knnc3gXjJLV1vdwFs2nLvh//nGtEh/.li04NodZJSfnc4jeCVHd7kKHGnq5MsenN.tO6Z.Cj/ groups: - sudo - docker Here value for passwd is a hash value. One of the below methods can be used...
1 comment
Read more

Consuming File System artifacts from Kubernetes Pods

When you are deploying an application which contains artifacts written on file system dynamically withing kubernetes (k8s), for example a tomcat server exposed to outside to deploy war files, you need to make sure the file system state is preserved always. Otherwise if the pod goes down, you might loose data. So one solution is to mount an external disk. Yes indeed you can do that. But how robust is that solution. Say something happened to the external disk. How can you recover the data? Use several disks and rsync to sync the data. Sounds a robust solution. Say you want to increase the reliability. And what happens if rsync process get killed. How much will it cost to make it's reliability closer to 100%? We have a robust, simple solution. It's using gluster to save data. [1] [2] We install a pod named gluster for each node. There is an additional disk attached to each node which will be used as the data storage for gluster. This disk is formatted in a special forma...
Post a Comment
Read more