Hi Colin, Thanks for bringing this up.
Yes, we could do with an existing Grant Type. When generating an Application Access Token we allow specifying validity period through Store UI. It's because none of the existing Grant Types accept validity period as a parameter, we are thinking of doing it through an extended Grant Type. Even WSO2 Identity Server might support changing validity period , other Authorization Servers might not allow that, as validity period is more like a server configuration and not something that can be changed per token. If someone doesn't need to change validity period through UI, then they can use an existing Grant Type. On Wed, Feb 18, 2015 at 9:07 AM, Colin Roy-Ehri <[email protected]> wrote: > +1 for these enhancements. > > I wonder if #1 the Extended Grant Type could cause unnecessary complexity > for the External Authorization server? I think #1 is a necessary feature, > but we could make simple grant types an option. For initial configuration > of an External Authorization server, it may be easier to work with the > default Oauth2 Grant Types. Perhaps we could have a configuration point > for the External Authorization server, i.e. <useExtendedGrantTypes> . Just > an idea. > > -Colin > > Thanks, > Colin Roy-Ehri > Software Engineer > *WSO2, Inc. : wso2.com <http://wso2.com/>* > *Mobile* : 812-219-6517 > > On Mon, Feb 16, 2015 at 5:53 AM, Amila De Silva <[email protected]> wrote: > >> Hi All, >> >> With API Manager 1.9.0, capability will be provided to plug in an >> External Authorization server. With this change, Authorization Server will >> be the only entity creating OAuth clients, and issuing access tokens. >> >> In order to seamlessly support some of the existing APIM features, >> certain changes should be done on the Store: >> >> 1. Generating Application Token using an Extended Grant Type >> >> As of now, Store UI allows to specify a validity period when Generating >> an Application Access Token. In the previous releases this was possible, >> since KeyManager component could directly access the tables where tokens >> are kept. So after generating a token through UI, Store could update the >> newly generated token giving a preferred validity period. After decoupling >> Authorization Server, Store would no longer be able to do this, through a >> direct DB call. Solution to overcome this problem would be to use an >> entirely new Grant Type to Generate the Application Access Token. The new >> Grant type would accept validity period as a new parameter and use it when >> generating the Application Access Token. >> >> >> 2. Using a Separate Table to store Application Access Tokens >> >> Currently, when rendering the UI, Store gets the Access Token by querying >> the Database directly. After decoupling AS, if we are to Display the >> Application Token, we would have to Keep the token in a separate Table. In >> this scenario, Store would act as another client App created on the AS and >> the Table for storing tokens will be used as a temporary storage. This >> means that only the most recent Access Token will be kept in, and the table >> won’t be used to obtain token meta data (such as validity period , Consumer >> Key) during an API invocation. >> >> >> 3. Generate the token only using /token, /authorize endpoints >> >> First time when creating an Application Access Token, Store calls >> APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token. >> This method, simply creates a token and write it down to >> IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when >> moving forward, we would have to obtain the the Application Access Token >> only using standard OAuth endpoints. >> >> >> 4. Determining the type of a token using a scope >> >> In API Manager, the type of the token (whether it is Application or >> Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token. >> Token Type is used when validating API Invocations (When defining a >> resource, the type of token required to access it can be specified, and a >> resource can be only accessed with a token of the specified type). Since >> the type of the token is tightly coupled with our implementation of Tokens, >> to make it usable across different Authorization Servers, Token type will >> be mapped to a scope. So Application Tokens will have a scope like >> am:application_token (we can make the scope name configurable). When a >> token is generated through the Store UI, Store will request the token with >> this scope. >> >> >> These are the major changes required for the Store to function properly. >> Would appreciate your feedback on these. >> >> -- >> *Amila De Silva* >> >> WSO2 Inc. >> mobile :(+94) 775119302 >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
