GuardOAuth2: R6 class for the OAuth 2.0 Guard
In fireproof: Authentication and Authorization for 'fiery' Servers
GuardOAuth2 R Documentation
R6 class for the OAuth 2.0 Guard
Description
This class encapsulates the logic of the oauth 2.0 based authentication
scheme. See guard_oauth2() for more information
Super class
fireproof::Guard -> GuardOAuth2
Active bindings
open_apiAn OpenID compliant security scheme description
Methods
Public methods
-
-
-
-
-
-
Inherited methods
Method new()
Constructor for the class
Usage
GuardOAuth2$new(
token_url,
redirect_url,
client_id,
client_secret,
auth_url = NULL,
grant_type = c("authorization_code", "password"),
oauth_scopes = NULL,
validate = function(info) TRUE,
redirect_path = get_path(redirect_url),
on_auth = replay_request,
user_info = NULL,
service_params = list(),
scopes_delim = " ",
name = NULL
)
Arguments
token_urlThe URL to the authorization servers token endpoint
redirect_urlThe URL the authorization server should redirect to
following a successful authorization. Must be equivalent to one provided
when registering your application
client_idThe ID issued by the authorization server when
registering your application
client_secretThe secret issued by the authorization server when
registering your application. Do NOT store this in plain text
auth_urlThe URL to redirect the user to when requesting
authorization (only needed for grant_type = "authorization_code")
grant_typeThe type of authorization scheme to use, either
"authorization_code" or "password"
oauth_scopesOptional character vector of scopes to request the
user to grant you during authorization. These will not influence the
scopes granted by the validate function and fireproof scoping. If named,
the names are taken as scopes and the elements as descriptions of the scopes,
e.g. given a scope, read, it can either be provided as c("read") or
c(read = "Grant read access")
validateFunction to validate the user once logged in. It will be
called with a single argument info, which gets the information of the user
as provided by the user_info function. By default it returns TRUE
on everything meaning that anyone who can log in with the provider will
be accepted, but you can provide a different function to e.g. restrict
access to certain user names etc. If the function returns a
character vector it is considered to be authenticated and the return value
will be understood as scopes the user is granted.
redirect_pathThe path that should capture redirects after
successful authorization. By default this is derived from redirect_url
by removing the domain part of the url, but if for some reason this
doesn't yields the correct result for your server setup you can overwrite
it here.
on_authA function which will handle the result of a successful
authorization. It will be called with four arguments: request, response,
session_state, and server. The first contains the current request
being responded to, the second is the response being send back, the third
is a list recording the state of the original request which initiated the
authorization (containing method, url, headers, and body fields
with information from the original request). By default it will use
replay_request to internally replay the original request and send back
the response.
user_infoA function to extract user information from the
access token. It is called with a single argument: token_info which is the
access token information returned by the OAuth 2 server after a successful
authentication. The function should return a new user_info
list.
service_paramsA named list of additional query params to add to
the url when constructing the authorization url in the
"authorization_code" grant type
scopes_delimThe separator of the scopes as returned by the service.
The default " " is the spec recommendation but some services cough
github cough are non-compliant
nameThe name of the guard.
Method check_request()
A function that validates an incoming request, returning
TRUE if it is valid and FALSE if not.
Usage
GuardOAuth2$check_request(request, response, keys, ..., .datastore)
Arguments
requestThe request to validate as a Request
object
responseThe corresponding response to the request as a
Response object
keysA named list of path parameters from the path matching
...Ignored
.datastoreThe data storage from firesale
Method reject_response()
Upon rejection this guard initiates the grant flow to obtain
authorization. This can sound a bit backwards, but we don't want to
initiate authorization if the authorization flow doesn't need it
Usage
GuardOAuth2$reject_response(response, scope, ..., .datastore)
Arguments
responseThe response object
scopeThe scope of the endpoint
...Ignored
.datastoreThe data storage from firesale
Method register_handler()
Hook for registering endpoint handlers needed for this
authentication method
Usage
GuardOAuth2$register_handler(add_handler)
Arguments
add_handlerThe add_handler method from Fireproof to be called
for adding additional handlers
Method refresh_token()
Refresh the access token of the session. Will return TRUE
upon success and FALSE upon failure. Failure can either be issues with
the token provider, but also lack of a refresh token.
Usage
GuardOAuth2$refresh_token(session, force = FALSE)
Arguments
sessionThe session data store
forceBoolean. Should the token be refreshed even if it hasn't
expired yet
Method clone()
The objects of this class are cloneable with this method.
Usage
GuardOAuth2$clone(deep = FALSE)
Arguments
deepWhether to make a deep clone.
Examples
# Example using GitHub endpoints (use `guard_github()` in real code)
github <- GuardOAuth2$new(
token_url = "https://github.com/login/oauth/access_token",
redirect_url = "https://example.com/auth",
client_id = "MY_APP_ID",
client_secret = "SUCHASECRET",
auth_url = "https://github.com/login/oauth/authorize",
grant_type = "authorization_code"
)
fireproof documentation built on Dec. 17, 2025, 5:09 p.m.
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
| GuardOAuth2 | R Documentation |
R6 class for the OAuth 2.0 Guard
Description
This class encapsulates the logic of the oauth 2.0 based authentication
scheme. See guard_oauth2() for more information
Super class
fireproof::Guard -> GuardOAuth2
Active bindings
open_apiAn OpenID compliant security scheme description
Methods
Public methods
Inherited methods
Method new()
Constructor for the class
Usage
GuardOAuth2$new(
token_url,
redirect_url,
client_id,
client_secret,
auth_url = NULL,
grant_type = c("authorization_code", "password"),
oauth_scopes = NULL,
validate = function(info) TRUE,
redirect_path = get_path(redirect_url),
on_auth = replay_request,
user_info = NULL,
service_params = list(),
scopes_delim = " ",
name = NULL
)Arguments
token_urlThe URL to the authorization servers token endpoint
redirect_urlThe URL the authorization server should redirect to following a successful authorization. Must be equivalent to one provided when registering your application
client_idThe ID issued by the authorization server when registering your application
client_secretThe secret issued by the authorization server when registering your application. Do NOT store this in plain text
auth_urlThe URL to redirect the user to when requesting authorization (only needed for
grant_type = "authorization_code")grant_typeThe type of authorization scheme to use, either
"authorization_code"or"password"oauth_scopesOptional character vector of scopes to request the user to grant you during authorization. These will not influence the scopes granted by the
validatefunction and fireproof scoping. If named, the names are taken as scopes and the elements as descriptions of the scopes, e.g. given a scope,read, it can either be provided asc("read")orc(read = "Grant read access")validateFunction to validate the user once logged in. It will be called with a single argument
info, which gets the information of the user as provided by theuser_infofunction. By default it returnsTRUEon everything meaning that anyone who can log in with the provider will be accepted, but you can provide a different function to e.g. restrict access to certain user names etc. If the function returns a character vector it is considered to be authenticated and the return value will be understood as scopes the user is granted.redirect_pathThe path that should capture redirects after successful authorization. By default this is derived from
redirect_urlby removing the domain part of the url, but if for some reason this doesn't yields the correct result for your server setup you can overwrite it here.on_authA function which will handle the result of a successful authorization. It will be called with four arguments:
request,response,session_state, andserver. The first contains the current request being responded to, the second is the response being send back, the third is a list recording the state of the original request which initiated the authorization (containingmethod,url,headers, andbodyfields with information from the original request). By default it will use replay_request to internally replay the original request and send back the response.user_infoA function to extract user information from the access token. It is called with a single argument:
token_infowhich is the access token information returned by the OAuth 2 server after a successful authentication. The function should return a new user_info list.service_paramsA named list of additional query params to add to the url when constructing the authorization url in the
"authorization_code"grant typescopes_delimThe separator of the scopes as returned by the service. The default
" "is the spec recommendation but some services cough github cough are non-compliantnameThe name of the guard.
Method check_request()
A function that validates an incoming request, returning
TRUE if it is valid and FALSE if not.
Usage
GuardOAuth2$check_request(request, response, keys, ..., .datastore)
Arguments
requestThe request to validate as a Request object
responseThe corresponding response to the request as a Response object
keysA named list of path parameters from the path matching
...Ignored
.datastoreThe data storage from firesale
Method reject_response()
Upon rejection this guard initiates the grant flow to obtain authorization. This can sound a bit backwards, but we don't want to initiate authorization if the authorization flow doesn't need it
Usage
GuardOAuth2$reject_response(response, scope, ..., .datastore)
Arguments
responseThe response object
scopeThe scope of the endpoint
...Ignored
.datastoreThe data storage from firesale
Method register_handler()
Hook for registering endpoint handlers needed for this authentication method
Usage
GuardOAuth2$register_handler(add_handler)
Arguments
add_handlerThe
add_handlermethod from Fireproof to be called for adding additional handlers
Method refresh_token()
Refresh the access token of the session. Will return TRUE
upon success and FALSE upon failure. Failure can either be issues with
the token provider, but also lack of a refresh token.
Usage
GuardOAuth2$refresh_token(session, force = FALSE)
Arguments
sessionThe session data store
forceBoolean. Should the token be refreshed even if it hasn't expired yet
Method clone()
The objects of this class are cloneable with this method.
Usage
GuardOAuth2$clone(deep = FALSE)
Arguments
deepWhether to make a deep clone.
Examples
# Example using GitHub endpoints (use `guard_github()` in real code)
github <- GuardOAuth2$new(
token_url = "https://github.com/login/oauth/access_token",
redirect_url = "https://example.com/auth",
client_id = "MY_APP_ID",
client_secret = "SUCHASECRET",
auth_url = "https://github.com/login/oauth/authorize",
grant_type = "authorization_code"
)
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
Embedding an R snippet on your website
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.