Generating bearer tokens

[TedHolt]

I need to generate an OAuth 2.0 bearer token for the server side of a Restful web service. I also must handle token validation and expiration, of course. Has anybody done this already & if so, can you give me some sage advice on the best way to go about this?

TIA.

[dhirajt30@gmail]

Hi Ted, did you come right with this requiremet? I also have to protect my IBM i with OAuth. Do you know how to configure OAuth on IBM i to be able to validate a token passed to IBM i?

[TedHolt]

The customer decided not to use bearer tokens, as both systems were in house. No customer has asked since, so I still haven't had to do this type of authorization.

[Scott Klement]

This is an unusual requirement. Let me explain:

Normally when people use OAuth2 it is because they want to share the signon with something else. For example, log into Gmail, Facebook, Twitter or GitHub and have the same logon work across other applications.

You have probably seen this in use on web sites on the Internet. Many sites will say "Login With your Gmail Account" (or similar). That's what that is... they will use OAuth2 to let you link-up your Gmail account with their system so that you can use your Gmail credentials to log in. And that is a very common scenario.

But in that case, you don't need to generate the bearer token. Instead, when the user logs in, it passes the bearer token already created. You call an API on Gmail (or one of the other sites, etc) to validate that the token is valid and get account information from that site. You don't have to generate the token yourself.

If you are generating the token, that would imply that you are taking the role that someone like Gmail or Facebook normally takes. In other words, you are hosting the login repository that will be shared across many sites. That is not a common requirement. But, if that's what you need to do, you will either need to hire someone who is very good at cryptography to write this capability for you, or you will have to find an existing OAuth package. I don't know of one for RPG, but there are some for other popular languages, such as Node.js, etc.

But most people using OAuth2 on IBM i will just be calling REST APIs provided by organizations like Facebook, Google, Twitter, Microsoft, etc, to allow the login from the other sites, they won't be generating the tokens themselves. So in that case, you are just calling REST APIs, which you can easily do from RPG or anything else.

[priceaj]

I'd like to contradict the above slightly, OAUTH 2.0 is not just used to login using x (I believe thats the basis of OIDC which does use OAUTH 2.0 but is an extension not the main use)

It's main function is to authorise access to a resourse.

There are two main grant types:

1. Client credentials
2. authorizaton code

Client credentials is generally used for machine to machine communication (to give an application access to it's own resourses)
Authorisation code is to allow an application to act on an end users behalf (think user giving a banking app access to their bank transactions, or github giving access to gitkraken to allow it to submit pull requests on your behalf)

There is a write up of which grant types are used where here: https://auth0.com/docs/get-started/a...w-should-i-use

I have written and implemented a version of the client credentials grant on the IBMi (unfortunately I can't open source this) to allow our tennant's to write applications to be authorised to the RestAPI endpoints which allow access to their own data.

The client registers an application, is provided with a ClientID and Secret (Secret is hashed and salted before it's stored so it can not be retreived, IBMi has cryptography API's like Qc3CalculateHash for these operations, but as Scott said make sure you know what you are doing!). Then they can use this to generate a token via a RestAPI endpoint and use the token on later requests (until expiry), token is checked and used to make sure that only resourses requested are allowed.

Authorizaton code is far more complicated to implement... luckily we don't have user facing apps, so that wasn't a problem for us!

The best resourse for a specification to implement an OAUTH 2.0 server that I have found is here https://www.oauth.com/oauth2-servers/background/