I may need to implement some secured REST services in the next few months. I've deployed a few REST services so far, but none of them were secured, so I need to get more familiar with this.
I would assume that I should be looking into oauth2, but it occurs to me that perhaps for at least one particular application, I might be able to do something simpler. For one particular application, I already have a "skeleton" using an enterprise-specified login service that presents its own login page and also facilitates authorization features. As a result, I can provide a simple entry point that can read an authenticated user name and authorization properties. It seems to me, that in this context, oauth2 is probably not the right fit. I would think that I could now generate some sort of a digest value that I could send to the front-end client (javascript). I'm not sure what protections I need to provide for that digest value. Perhaps simply replacing it with new values when the current value is sent on a request might suffice. What is a reasonable approach for this?
