php - Design of Restful API with HTTP Basic Authentication -

note: know there lots of other stackoverflow questions dealing topic. i've read through many of them, many other websites. still have following questions.

so, i'm building rest api new product. @ time api entirely private consumption our websites , phone apps. however, i'm thinking might smart design api can made public in future.

authentication

while i've looked @ oauth, think http basic authentication on ssl plenty secure enough our api. understand http basic authentication on ssl viable way of authenticating rest api. it's quite simple, appealing me since i'm new api development.

authorization

if user logs in api using username , password, given access parts of api. meaning they'll have access own content, not content of other users. further, may limited can do.

in addition user accounts, plan have other other (non user) accounts more global administrative tasks. these accounts potentially have full access api.

is design? or, bad authenticate user in way? should authenticating clients (ie. apps) way?

sessions

my big question is, when logging user our web app, how manage sessions? rest stipulates sending username , password each request. further, rest api's stateless, cannot manage sessions there. however, need track they've logged web app somehow. can't possibly login manually each request.

one approach is, after user logs in, save login credentials (email & password) php session. then, each subsequent request api use credentials. however, saving usernames , passwords in php session feels wrong , unsafe. if not done way, how people managing sessions when interacting rest api?

the phone apps easier, can save user's login credentials keychain.

can design questions?

i know question bit old , maybe finished work, i'd give tips. maybe these or in future. :)

authentication

http basic auth on ssl quite simple, that's true, not secure think. have install 1 "fake" ssl cert on client , man in middle attack can sniff traffic.

how install fake certificate? it's not hard in browser lot of users click on ok when see huge red warning screen. on mobile example: http://cryptopath.wordpress.com/2010/01/29/iphone-certificate-flaws/

with solution have intercept traffic once , you'll have user's password!

my tip: generate temporary password @ login , use in every other requests. attacker have intercept login process password , if store pass locally on phone example it's harder. (and of course can add expiration etc...)

authorization

i don't understand do. user access management thing, depends on given project.

session

not rest apis, teh whole http world stateless. if use php session stores session id in cookie on client side , browser sends cookie value every time server.

the users don't have login every time. log in once , token/temporary password etc... , (or if don't use these stuff) send basic auth header @ every requests. way can track sent request, because who's user , can store , link data on server.

there many ways deal users. basic auth 1 of them. , check this: oauth's tokens , sessions in rest "oauth tokens explicitly session identifier, ..."

you don't have store user's password , email, have check headers/cookies/etc... client in every requests.

the phone apps easier, can save user's login credentials keychain.

they can, saving user's real password on phone bad practice. save time limited token bit better. :)

in every other languages can store values if want. example if want use python client api: authenticates , stores token or needs in variable , @ every other requests uses stored data.

one more sidenote:

however, saving usernames , passwords in php session feels wrong , unsafe.

true that's unsafe, (real) php sessions stored on server side , said stores single session id on client side. can session id, impersonate given user. (there countermeasures example ip check, etc...)