Marvin Tener · Jan 18, 2018 go to post

If you are generating access tokens, then you are probably on the server where the access tokens are stored in OAuth2.Server.AccessToken.  OAuth2.AccessToken is where the access tokens are stored on the client. 

Both of these tables must be accessed from the %SYS namespace and privileges to access CACHESYS database are required.

Marvin Tener · Nov 8, 2017 go to post

There is no simple answer.  There are a number of choices depending on how you handle users and your security concerns.

First let me point you to the documentation at http://localhost:57774/csp/docbook/DocBook.UI.Page.cls?KEY=GOAUTH

I'll mention two approaches:

1. In the authorization server authentication callback routine, you can setup a property which will later be included in the JWT which acts as the access token.  This property would specify the access rights.  In this case, the JWT must be signed.

2. On the client machine Cache security roles may be associated with the users which control their access rights.  Then ZAUTHENTICATE may be used to log in the appropriate user based on the user associated with the access token.

Their are lots of possible variation here.  I suggest a read of the documentation and some experimentation.  At that point if all is not clear, a call to support to talk through the options in your specific situation would be the next step.

Marvin Tener · Jun 6, 2017 go to post

I thought about use of RFC 7523 a bit more and realized that in many situations it is appropriate to use the client credentials grant type from RFC6749 with the request authenticated using a JWT per RFC 7523.  This usage is supported in 2017.1 and will give you many of the security attributes of JWT grant type.