Hi All, This is related to resolving bug [1].
With the previous API Manager releases, when APIs are accessed using invalid tokens, specific errors for such failures were sent. For example, if the API was accessed using an expired token, response with 900903 as the error code was sent, and if the failure is due to an Invalid token the response code 900901 was sent. In previous releases it was possible to get the token state, since we had direct access to the DB where tokens are stored. But when providing the ability to plug in Third party Authorization Servers, we only have access to information exposed by the Authorization Server. According to [2], an Authorization Server may only state the token as invalid, not exposing specific reasons about the failure. In such cases, API Manager cannot provide exact details on why the failure has occurred. In a security point of view, general practice is to provide least information about a failure, when invalid credentials are used. To make the behaviour consistent, irrespective of whether the Auhtorization Server is a third party one or the default one, with 1.9.0 we’ll be sending a generic failure when the token is invalid. With this change the same error code (900901) will be sent, when the token is expired or inactive. Impact: If there are Client Apps, that take different paths to refresh the token depending on the error code, those have to act upon the general error code (900901) from this release onwards. This has to be done as a part of the migration. Please share your thoughts on this. [1] https://wso2.org/jira/browse/APIMANAGER-3578 [2] https://tools.ietf.org/html/draft-ietf-oauth-introspection-08 [3] https://docs.wso2.com/display/AM190/Error+Handling -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
