evaluate whether we should implement application-only authentication:

"

Twitter offers applications the ability to issue authenticated requests on behalf of the application itself (as opposed to on behalf of a specific user). Twitter’s implementation is based on the Client Credentials Grant flow of the OAuth 2 specification. Note that OAuth 1.0a is still required to issue requests on behalf of users.

Application-only authentication doesn't include any user contet. This means that you can only make requests to a Twitter API that doesn't require an authenticated user.

With application-only authentication, you can perform the following:

Pull user timelines;
Access friends and followers of any account;
Access lists resources;
Search in Tweets;
Retrieve any user information, excluding the user's email address;"

see https://developer.twitter.com/en/docs/basics/authentication/overview/application-only#issuing-application-only-requests

Write a description of the code found in the R file. It should also include some of the information given on the Google Open ID website.
⚠️ The token expires after one hour. The user has to implement a refresh token path!

for backlog.

as a user i want to be able to quickly implement a https ready plumber API.

https://developer.twitter.com/en/docs/basics/authentication/overview/3-legged-oauth

Currently, jwt_split does not export the headers of the token.

maybe we can do mulitple filters to allow for more granular authorization?
idea:

• in authenticate route, add a "scope" to claims
• one filter for general scope
• one filter for "admin" scope

develop an example application

• locally
• deploy

ensure that we are safeguarded against this vulnerability:
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries//

I'm currently trying to implement the unboxed serializer for jsonlite::toJSON.

Is this possible with sealr?

I tried

pr$handle(
  "GET",
  "/secret",
  function (req, res) {return("Access to route requiring authentication was successful.")},
  serializer = "unboxedJSON"
)

which results in status 500, message [1] "ERROR: Serializers must be closures: 'unboxedJSON'" when trying to call this with httr

see https://github.com/curso-r/auth0
maybe we could do something similar for sealr.

we could return TRUE / FALSE instead of forwarding within the function itself.

This would leave more possibilities to the user.

e.g. currently it is only possible to preempt one filter which makes more granular authorization (e.g. per endpoint) impossible. If the function only returned TRUE / FALSE the user could also use it inside endpoints (couldn't they?).
alternatively we could try to cut the functions so that there is always a function that does the check that returns TRUE / FALSE and a corresponding filter function that forwards..

@jandix : what do you think?

We need a valid oauth2_google jwt to test the function properly. How do we include this token in the tests since it is only valid for an hour?

we should add a section to the docs with best practices / considerations.
Topics:

• local storage vs cookies.
• XSS / CSRF
• SQL injection

best practices for browser apps: https://developers.google.com/identity/work/saas-browser-apps

General issue: CSRF attacks

warnings to docs

for each authentication strategy, i want at least one accompanying working example (mainly to show how to implement the /authenticate route.

move example from readme to examples folder. add "database" .

Currently, we only check if the token is valid. We should offer the option to filter a certain audience, such as "user" or "admin".

https://developers.google.com/identity/protocols/OpenIDConnect#createxsrftoken

"You must protect the security of your users by preventing request forgery attacks. The first step is creating a unique session token that holds state between your app and the user's client. You later match this unique session token with the authentication response returned by the Google OAuth Login service to verify that the user is making the request and not a malicious attacker. These tokens are often referred to as cross-site request forgery (CSRF) tokens."

standard claims as arguments with default = NULL, custom claims with ...

support to get a token from the cookie.

cookie needs to be called token (more flexibility would require another function argument and I'd like to avoid adding many more arguments).

• implementation
• documentation
• tests

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate

as per RFC 2616, we should include a WWW-Authenticate header in the 401 response.

" The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. "

IANA describes the authentication schemes: http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml

as an end user of the package, I can visit the github page of the package where example implementations (from examples folder) are presented / put into context.

as per #9 , jose decode does not fail automatically if the token is expired.

hence, we should check the exp claim ourselves (if it is there).

Open question:
what to do with that information? Return 401?
how can the user know that the token expired?
can we redirect to a refresh endpoint? 🤔
@jandix: your opinion?

rlang errors provide a better backtrace compared to base errors.

https://www.tidyverse.org/articles/2018/10/rlang-0-3-0/

see jose::jwt_split (not exported function).

Currently, we rely only on jwt_decode_hmac, but we should also support jwt_decode_sig if the user provides a valid public key object.