Home/ Questions/Q 7277803
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T22:47:25+00:00

I have just started reading on implementing RESTful web services and creating RESTful apis.

  • 0

I have just started reading on implementing RESTful web services and creating RESTful apis. I have understood the basic concept of REST but I have been scratching my head a bit on how I will implement it securely?

Say for example, my webapp has a user login process. After successfully logging in, what else should I pass in the RESTful request to authenticate on server???
What I can think of is the following process:

  • user logs in (POST username/password to API)
  • API responds with a userkey
  • userkey is stored locally
  • When making any further requests, I include this key in request be authenticated

But here it seems that userkey is a state which I am sending to API, but REST happens to be stateless. Also this is not too secure in case of sending GET requests.

Is OAUTH the solution to my dilemma? Or some other way? Can somebody guide me on this…

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    UserKey, or better call it token, is a client-side state. Your RESTful API will remain stateless since it stores this token no where.

    Usually this token is a combination of some segments (username, password, login date) hashed as MD5, SHA (or any other algorythm). Whenever client calls an operation of your RESTful API, your service will compare the incoming token with an on-the-fly generated one using the same segments. If both generated tokens are equal, request gets authenticated.

    There’s no problem with GET or POST methods: you’ll need to retrieve your token from query string or an HTTP header.

    The point to secure your connection is calling your RESTful API over SSL, so your communications will have a high degree of security.

    An important problem with GET and sending this token using query strings is maybe it’s too long and URL length limitations would prevent you from having a lot of arguments in addition to the token itself.

    In my opinion, you should go with POST verb, because you can send more data, it’s more flexible and you avoid giving problematic arguments in query string, which can be bad in terms of logging, since you’re going to log user names, passwords, tokens and other things, which are sensitive information that can compromise your users if a hacker steals your logs (or some unwanted person checks your log too).

    • 0