notes.readonly. When a client application authenticates on behalf of a user, it requests one or more of these scope identifiers to be granted to the access token. Valid scopes will be stored with the access token, so that the scope can be referenced by subsequent uses of the access token.
Authorizerretrieves the token's scope. After the request is validated, the
Authorizerstores scope information in
Request.authorization. Linked controllers can use this information to determine how the request is handled. In general, a controller will reject a request and send a 403 Forbidden response when an access token has insufficient scope for an operation.
Authorizerhandles a request, it creates an
Authorizationobject that is attached to the request. An
Authorizationobject has a
scopesproperty that contains every scope granted for the access token. This object also has a convenience method for checking if a particular scope is valid for that list of scopes:
Requestis only valid after the request is handled by an
Authorizer. It is
Authorizermay also validate the scope of a request before letting it pass to its linked controller.
NoteControllerwill only be reached if the request's bearer token has 'notes' scope. If there is insufficient scope, a 403 Forbidden response is sent. This applies to all operations of the
Scopeannotation may be added to
ResourceControlleroperation methods for this purpose.
Scopeannotations, you must link an
Authorizerprior to the
ResourceController, but it is not necessary to specify
Authorizercontains multiple scope entries, an access token must have scope for each of those entries. For example, the annotation
@Scope(['notes', 'user'])requires an access token to have both 'notes' and 'user' scope.
conduit authcommand-line tool. When creating a new client identifier, include the
conduit auth set-scope:
com.app.mobileclient ID to grant access tokens with 'notes' and 'users' scope. If a client application requests scopes that are not available for that client application, the granted access token will not contain that scope. If none of the request scopes are available for the client identifier, no access token is granted. When adding scope restrictions to your application, you must ensure that all of the client applications that have access to those operations are able to grant that scope.
AuthServerDelegate. By default, this method returns
AuthScope.Any- which means there are no restrictions. If the client application allows the scope, then any user that logs in with that application can request that scope.
AuthScopes that are valid for the authenticating user. The following example shows a
ManagedAuthDelegate<T>subclass that allows any scope for
@conduit.dart.comusernames, no scopes for
@hotmail.comaddresses and some limited scope for everyone else:
getAllowedScopesis the user being authenticated. It will have previously been fetched by the
AuthServerfetches this object by invoking
AuthDelegate.getResourceOwner. The default implementation of this method for
ManagedAuthDelegate<T>only fetches the
hashedPasswordof the user.
getResourceOwnerto fetch these attributes. For example, if your application's user has a
roleattribute, you must fetch it and the other four required properties. Here's an example implementation:
scopeparameter must be added to the form data body. This parameter's value must be a space-delimited, URL-encoded list of requested scopes.
AuthCodeController, this same query parameter is added to the initial
GETrequest to render the login form.
:character. For example, the following is a hierarchy of scopes related to a user and its sub-resources:
user(can read/write everything a user has)
user:email(can read/write a user's email)
user:documents(can read/write a user's documents)
user:documents:spreadsheets(can read/write a user's spreadsheet documents)
user:emailscope, it only allows access to a user's email. However, if the access token has
userscope, it allows access to everything a user has, including their email.
user:documentsscope can access all of a user's documents, but the scope
user:documents:spreadsheetsis limited to only spreadsheet documents.
user:email:write. However, an access token with
user:email:writedoes not have permission to read email and this is likely unintended.
.at the end of a scope string. For example,
user:email.readonlygrants readonly access to a user's email whereas
user:emailgrants read and write access.
user:emailcan both access
user:email.readonlyprotected resources and actions, but
user:email.readonlycannot access resources protected by
user:documents.readonly:spreadsheetsis not valid, but