Users/axsuarez/app authorization

[axelsrz]

This pull request introduces significant updates to the AgentApplication class and related components to enhance authorization and OAuth flow management. The changes include the addition of a new Authorization class, updates to the ApplicationOptions class for OAuth configuration, and the removal of deprecated or unused methods. Below is a breakdown of the most important changes:

Authorization and OAuth Enhancements

• Introduced a new Authorization class to manage OAuth flows, including token retrieval, flow state management, and sign-out functionality. This class also supports setting a handler for successful sign-ins. (libraries/Builder/microsoft-agents-builder/microsoft/agents/builder/app/oauth/authorization.py)
• Updated ApplicationOptions to include an optional authorization field for configuring OAuth handlers. (libraries/Builder/microsoft-agents-builder/microsoft/agents/builder/app/app_options.py)
• Replaced the _auth field in AgentApplication with an instance of the new Authorization class and integrated it into the initialization process. (libraries/Builder/microsoft-agents-builder/microsoft/agents/builder/app/agent_application.py) [1] [2]

Codebase Simplification and Cleanup

• Removed the _run_ai_chain method and associated logic, as it is no longer in use. (libraries/Builder/microsoft-agents-builder/microsoft/agents/builder/app/agent_application.py)
• Replaced re.match with re.fullmatch in text matching logic to improve accuracy. (libraries/Builder/microsoft-agents-builder/microsoft/agents/builder/app/agent_application.py)

API Improvements

• Added a new on_sign_in_success method to AgentApplication for registering event listeners triggered upon successful user sign-ins. (libraries/Builder/microsoft-agents-builder/microsoft/agents/builder/app/agent_application.py)

Adjustments to Core Components

• Increased the leeway for JWT token validation from 5 seconds to 300 seconds to account for potential clock skew. (libraries/Core/microsoft-agents-authorization/microsoft/agents/authorization/jwt_token_validator.py)
• Made the token_exchange_resource field in the OAuthCard class optional. (libraries/Core/microsoft-agents-core/microsoft/agents/core/models/oauth_card.py)

Miscellaneous

• Updated __init__.py files to include new imports for Authorization and other related components. (libraries/Builder/microsoft-agents-builder/microsoft/agents/builder/app/oauth/__init__.py, test_samples/app_style/shared/__init__.py) [1] [2]

[tracyboehrer]

What are the use cases for on_sign_in_success? Is not the continuation activity an indicator of success? Does this mean they have two paths to execute a turn in? One for on_success, and one in the continuation handler?

[axelsrz]

What are the use cases for on_sign_in_success? Is not the continuation activity an indicator of success? Does this mean they have two paths to execute a turn in? One for on_success, and one in the continuation handler?

@tracyboehrer Yes... kinda. on_sign_in_success will only be triggered when finishing the oauth flow successfully for the first time (not when already have the token). But yes, in that instance it will run on_sign_in_success and then the continuation activity. This use case is fairly limited to "successfully signed in" messages and such

[tracyboehrer]

What are the use cases for on_sign_in_success? Is not the continuation activity an indicator of success? Does this mean they have two paths to execute a turn in? One for on_success, and one in the continuation handler?

@tracyboehrer Yes... kinda. on_sign_in_success will only be triggered when finishing the oauth flow successfully for the first time (not when already have the token). But yes, in that instance it will run on_sign_in_success and then the continuation activity. This use case is fairly limited to "successfully signed in" messages and such

So that would be explained to the dev as "lets you tell the user they are signed in"? But we can't really limit it to that. They can do anything they want. Maybe that's ok. Maybe the dev wants to store something in state when this happens? "User signed in on {date/time}", then when SignOut is called store that?

It's super easy to explain "on sign in failure". "Gives dev the opportunity to take other action... Handoff to a live person, tell them to call support, etc....).

Honest question though and not a criticism. If I can imagine one case, there are certainly others. Looking for symmetry across languages.