OAuth 2.0
OAuth 2.0 emerged as a second iteration of the security framework endorsed by big names like Facebook, Google and Microsoft and it set out to standardise how API access delegation would work, i.e. how other services could access your data on your behalf.
You’ve seen this when you log in or register with your Facebook or Google account. OAuth2 never aimed to be a complete solution, it just laid the grounds and best practices to achieve API security standardisation. So some gaps had to be filled in, and among them were Bearer tokens.
Bearer tokens are used to authorize requests to protected resources and to quote RFC spec they are “a string representing an access authorization issued to the client“, the main idea was to remove user’s credentials from authorization headers and instead issue a token which would replace user’s credentials.
This is, in essence, the idea behind refresh token flow which you can read about in detail here (also check this great article). To understand this, it’s best to take a look at the diagram, and I’m a huge fan of the awesome RFC ASCII art diagrams.
So to force a client to get a new token you would just invalidate it server-side and client will automatically get a new one. Well… not exactly, the client will have to do it manually on each request, not what we hoped for. Let’s see an example…
To use Infor API with ION is very simple