Thanks Rick, I'm working on mobile version of my web system and I'm planning to use Flutter for this mobile app. I was thinking to use token, generated by encrypted JSON, which will include user details, some other global variables, date/time generated, expiration time etc. My idea is to not store this token in table, but once it's generated by the Rest API, it will return it to user. User will decrypt JSON and will get all global variables he needs. On each request to the API, user will send same token and Rest API will validate token on each request e.g. will check if it's valid, if it's expired etc. I'm not intended to use JWT as it's a bit too complicated and I don't need the extra data it provides. I will have a look at wwEncryption class to see how I can encrypt json into token.

I'm not sure that's such a good idea because that requires that the client has a key to decrypt the data. If the client has it, it can be read and you might as well send unencrypted data over the wire. Even in a mobile app this isn't a good idea and definitely not in a JavaScript client application where one can easily get at the code.

You should keep user authentication data and 'data' separate even if the data is about the user. Use the token to authenticate/authorize only and everything else separate. Only the server should hold the secrets and clients can retrieve what they need separately.

You also want to make sure the token stays small, because it goes over the wire with every single request regardless of whether you need the data embedded or not. The goal of authentication/authorization is to ensure the user is who she says she is, and map the user to something you can identify in your system. This means the user asks for a token and then sends it for authentication on each request that requires authentication (or simply all of em).

In a client application you typically need to retrieve client data only once after initial login. After that you cache it locally in a variable, so there's no need to pass this data around in every request.

+++ Rick ---

Rick, I think you are correct. Only the server should hold the key to generate the token and token should only be used by the user to authenticate.

However, I'm thinking about a way to store user's information inside a json, which then is encrypted into a token, which then to be returned to the client. Client will then send token on each request, server will get the token, decrypt it and get the user's information, then use it to extract data for the client.

Of course, my idea is to only have just a few important IDs inside the token e.g. User ID and Customer ID (id of organization to which user belongs). My main goal is to not store the token in a table at server side so Rest API really acts as restful service and not similar to normal web server, which stores the session details into wwSession etc.

The only thing I'm not sure yet is about token expiration e.g. should it contain something like DateGenerated and number of seconds which will cause token to expire. Do you think it will work, if this information is inside token and server decrypt token and then checks it?

Again - if you're encrypting on the client in any way that means you have the key on the client which means it's not secure. If that's the case there's no reason to encrypt anything. You likely can't encrypt on the client anyway because the crypto you need is likely not there on the client (not sure about flutter but RSA encryption is not a thing you can do in JavaScript for example).

For real security it's pointless to encrypt if the key exists on the client because any hacker that is interested enough can find the key and decrypt the data

That's why you want to keep the auth and 'data' separate. If necessary you can encrypt the token on the server with the data you need and pass it back to the client, but the client can't do anything with the token except use it as a 'token' to pass back - it can't read the data inside of it.

In that scenario you can then use the token as a sort of self-contained viewstate that the client passes to you without the ability to modify it.

+++ Rick ---

Thanks Rick. My idea is client only to receive the token and attach it to each request.

The token will be encrypted json, which will contain 2 IDs, date when token is generated and timeout in seconds.

Client will not have the key and will not decrypt the token. Only the server will decrypt it when token received via request. Then it will extract IDs etc and will check if token is not expired. IDs will be used to extract information from database and return json to client. I think this way security will be implemented properly and also server will not store any client information in table e.g. will work as real Restful API service.

Yes that should work.

Not sure what makes this more RESTful than using a database - that has nothing to do with how you pass information across or how you store data.

+++ Rick ---

Well, the idea of Restful API is to only get request and token and return json, without keeping session. At least this is how it’s always explained. By the way, I just had another idea - can I run separate RestProcess inside my existing web server, which will only work with the mobile app and the regular process class to keep working with the web system? I think this will help me use the same COM servers. At present we have 5 different web systems, each with separate database and separate COM servers and it would be a nightmare if I need to create 5 new Rest API. It would be great if I can integrate the RestService process inside existing web servers, just not sure whether specific URL would be enough to do the trick?

No that's not right. REST has nothing to do with how a Web application operates or what data protocols it uses to store and receive state. That's is an application concern. REST only concerns itself with the network transfer layer of how the request travels over HTTP. How you manage data in the server application has nothing to do with that other than the final output layer that returns the data.

HTTP systems are always stateless - whether you keep a session on the server or not. I think that is the thing you're probably thinking of here. And even if you use session state (which is not what I was suggesting but that would work too), that is not state that is passed to the client. That is state that is acquired when the user provides his authentication token.

I can guarantee you when you're interacting with any complex REST API (think FaceBook or Twitter) there's a database that tracks users and profiles and those are not passed over the wire in an encrypted token. What happens on the server to track users has no bearing on the RESTful-ness of an API. The only thing that matters for REST is the API interface that the client sees and interacts with.

That's not to say you can't use what you describe - that's totally fine. But that doesn't make your API/Request any more or less RESTful. It's the HTTP syntax, URL, request and result content that makes it so.

FWIW REST is a very vaguely defined concept - there's no REST standard, just a set of recommendations which boil down to:

• URL based API interface
• token based authentication
• state-less client operation
• JSON/XML results + binary data (images, files)
• Use of HTTP Verbs for identifying operations

+++ Rick ---

Thanks Rick. I’ll have a think about the option to store the token and user information in a table. Actually I may test both approaches and will go for faster one.

Like I said, there's no requirement for using session or tables or using a token. Use whatever works.

If you're using a token and table don't bother making it two way - just create a one-way hash and store it in the database along with a mapping key to a user id or whatever you need to identify the user. Encryption/Decryption is not very fast and the data access especially on a small lookup table is likely quicker (not that that speed will matter much).

+++ Rick ---

Thanks Rick. I was thinking about some table, similar to wwSession.

However instead of sessionId, it will contain the token and I can easily get user details when client sends the token to server.

By the way, can I implement the restservice process into existing web application? I assume I should have a specific URL part, which will trigger Rest Api process?

Rick,I think I've found it. All I need is to create a new script map, which then to link to my new rest process into web server.

Thank you for all your help, Rick!

Yup that's the way to do it - using a wwRestProcess class handler.

As described in the Walk through here:

• Create a REST Service Classhttps://webconnection.west-wind.com/docs/_4iy15ut0v.htm

+++ Rick ---