RESTful API authorization/permissions using OPTIONS

Question

Are HTTP OPTIONS requests appropriate to determine a user's authorization?

I have seen HTTP OPTIONS requests used for preflight to check if a request is valid, but is it okay to use it to determine what access a user has to a specific resource?

Use case

A resource is display on a page. There is an edit form uses PUT to update the resource. If a request to OPTIONS /resource/1 shows it accepts PUT, an edit button is displayed.

Questions

1. Is an OPTIONS request suitable to the return the verbs that a specific user has access to determine authorization/permissions?

2. Should OPTIONS requests header information be used in frontend code (or just preflight vaidation)?

3. Are there any standards for determining an authenticated user's permissions via REST API?

Odoriferous

Did you ever settle on this approach? – Legation

@LeeviGraham I created a proof of concept implementation for a project, but chickened out before putting it in production. Ended up just making another endpoint to fetch for user roles. – Odoriferous

Answer 1

As per the Mozilla docs for OPTIONS answer to your question is "yes". However, we need to add Authorization checks for all HTTP Methods - GET, POST, PUT & DELETE, since actual data is accessed by these Methods.

Here are the reasons:

1. Usually OPTIONS is called before POST by Web Browsers (for CORS checks). Not sure this is called by all API clients (For eg. server to server communication)
2. Even if you add Authorization support for OPTIONS, you need to add it for all remaining methods of HTTP.

Resee