If there is a protected resource in the REST API, and I want to send a username / password from the mobile app to the rest service, then where do i store the username / password, and what is the proper way to generate it?

To be more specific, I want to be able to do the following:

1) create an account from within the android app
2) upon creation, the user gets credentials from the server so that he can access the rest api resources
3) the user saves these credentials as long as he is logged in. if he is logged out, he temporarily loses the credentials until he logs back into that specific account where the credentials were generated.

Sorry , I probably didn't explain this very well. Any help appreciated!

Step 1: Encryption?
Step 2: ???
Step 3: Profit

sorry? Not sure i understand where that falls into place. Does the user save encrypted information on their phone, or does the encrypted information get sent to the user by the server every time he logs in

it was a joke

Use hashing.

1) mobile device hashes password
2) mobile device sends hashed password
3) server checks against its own stored hashed user password

This way the password is never sent in the clear or known via the server (unless the server generates the hash for some reason but it should really be client side).

that makes sense. thank you.

edit:: this seems kinda problematic though, what if the user logs in from another device?

edit2:: nvm! seems like that won't be an issue... https://crackstation.net/hashing-security.htm

This post was edited by oOn on Mar 30 2015 06:46pm

Yep I guess I was wrong, you should make your server hash the passwords.

Just make sure its sent over SSL or similar.

A better approach may be to generate and return an access token from the login API endpoint.

1. Client sends username/password to /login
2. Server authenticates these credentials against it's database and generates an access token (a UUID or some kind of unguessable string), stores it in the database and returns this access token to the client
3. The client stores this token for the duration of its session and sends it along with any future API calls

When the server receives a request, it authenticates this token against its token repository and can infer any information it needs by joining it to the user table

This approach has some advantages:
- Access tokens are revokable
- Access tokens are unique per client instead of per user
- You're not storing the username and password on the client device

This

In plaintext under a folder named "Account Information" just like Sony