[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"detail-sidebar-cat-1-en-105":3,"doc-seo-306630-105":53,"doc-detail-306630-en":126},{"code":4,"msg":5,"data":6},0,"success",[7,14,19,24,29,34,39,44,49],{"id":8,"doc_module":9,"doc_module_name":10,"category_name":11,"show_sort_weight":12,"slug":13},11,1,"Template","Presentations",90,"presentations",{"id":15,"doc_module":9,"doc_module_name":10,"category_name":16,"show_sort_weight":17,"slug":18},12,"Resumes",80,"resumes",{"id":20,"doc_module":9,"doc_module_name":10,"category_name":21,"show_sort_weight":22,"slug":23},14,"Invoices",70,"invoices",{"id":25,"doc_module":9,"doc_module_name":10,"category_name":26,"show_sort_weight":27,"slug":28},15,"Posters",60,"posters",{"id":30,"doc_module":9,"doc_module_name":10,"category_name":31,"show_sort_weight":32,"slug":33},16,"Social Media",50,"social-media",{"id":35,"doc_module":9,"doc_module_name":10,"category_name":36,"show_sort_weight":37,"slug":38},17,"Forms",40,"forms",{"id":40,"doc_module":9,"doc_module_name":10,"category_name":41,"show_sort_weight":42,"slug":43},18,"Letters",30,"letters",{"id":45,"doc_module":9,"doc_module_name":10,"category_name":46,"show_sort_weight":47,"slug":48},21,"Paper Templates",5,"papers-templates",{"id":50,"doc_module":9,"doc_module_name":10,"category_name":51,"show_sort_weight":4,"slug":52},158,"General","general-158",{"code":4,"msg":54,"data":55},"ok",{"site_id":56,"language":57,"slug":58,"title":59,"keywords":60,"description":61,"schema_data":62,"social_meta":119,"head_meta":121,"extra_data":123,"updated_unix":125},105,"en","oauth-20-authorization-framework-draft-ietf-oauth-v2-30-standards-track","OAuth 2.0 Authorization Framework - draft-ietf-oauth-v2-30 - Standards Track","","OAuth 2.0 authorization framework specification describes how third-party applications obtain limited access to an HTTP service, either on behalf of a resource owner through an approval interaction or on their own behalf. It replaces and obsoletes the OAuth 1.0 protocol in RFC 5849. The memo is an Internet-Draft intended for Standards Track status, with defined scope for roles, protocol flow, authorization grants, token handling, refresh behavior, endpoints, security considerations, and extensibility.",{"@graph":63,"@context":118},[64,80,101],{"@type":65,"itemListElement":66},"BreadcrumbList",[67,71,74,77],{"item":68,"name":69,"@type":70,"position":9},"https://docshare.wps.com","Home","ListItem",{"item":72,"name":10,"@type":70,"position":73},"https://docshare.wps.com/template/",2,{"item":75,"name":51,"@type":70,"position":76},"https://docshare.wps.com/template/general/",3,{"item":78,"name":59,"@type":70,"position":79},"https://docshare.wps.com/template/oauth-20-authorization-framework-draft-ietf-oauth-v2-30-standards-track/306630/",4,{"url":78,"name":59,"@type":81,"image":82,"author":87,"headline":59,"publisher":90,"fileFormat":93,"inLanguage":57,"description":61,"dateModified":94,"datePublished":95,"encodingFormat":93,"isAccessibleForFree":96,"interactionStatistic":97},"DigitalDocument",{"url":83,"@type":84,"width":85,"height":86},"https://docshare.wps.com/thumbnails/oauth-20-authorization-framework-draft-ietf-oauth-v2-30-standards-track/306630.png","ImageObject",442,249,{"name":88,"@type":89},"Jasmine","Person",{"url":68,"name":91,"@type":92},"DocShare","Organization","application/pdf","2026-09-21","2026-09-19",true,{"@type":98,"interactionType":99,"userInteractionCount":9},"InteractionCounter",{"@type":100},"ViewAction",{"@type":102,"mainEntity":103},"FAQPage",[104,110,114],{"name":105,"@type":106,"acceptedAnswer":107},"What problem does the OAuth 2.0 authorization framework solve?","Question",{"text":108,"@type":109},"It enables third-party applications to obtain limited access to an HTTP service either on behalf of a resource owner via an approval interaction or on their own behalf.","Answer",{"name":111,"@type":106,"acceptedAnswer":112},"How does this specification relate to OAuth 1.0?",{"text":113,"@type":109},"The OAuth 2.0 authorization framework replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.",{"name":115,"@type":106,"acceptedAnswer":116},"What is the purpose and status of this Internet-Draft?",{"text":117,"@type":109},"It is submitted as an Internet-Draft in full conformance with BCP 78 and BCP 79, and it is intended as a Standards Track document.","https://schema.org",{"og:url":78,"og:type":120,"og:title":59,"og:site_name":91,"og:description":61},"article",{"robots":122,"canonical":78},"index,follow",{"doc_id":124,"site_id":56},306630,1789978383,{"code":4,"msg":5,"data":127},{"doc_id":124,"user_id":128,"nickname":88,"user_avatar":129,"doc_module":9,"category_id":50,"category_name":51,"doc_title":59,"doc_description":61,"doc_content":130,"file_id":131,"file_url":132,"file_type":133,"file_size":134,"view_count":73,"is_deleted":4,"is_public":9,"is_downloadable":9,"audit_status":9,"page_count":135,"language":136,"language_code":57,"site_id":56,"html_lang":57,"table_of_contents":137,"faqs":138,"seo_title":139,"seo_description":61,"update_tm":140,"read_time":35},2336478487870,"https://ap-avatar.wpscdn.com/davatar_085a072bc5b1113ac321206ff7593b45","OAuth Working Group Internet-Draft  \nObsoletes: 5849 (if approved)  \nIntended status: Standards Track  \nExpires: January 16 , 2013  \nD. Hardt , Ed. Microsoft  \nD. Recordon Facebook July 15 , 2012  \nTOC  \nThe OAuth 2.0 Authorization Framework draft-ietf-oauth-v2-30  \nAbstract  \nThe OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an [HTTP](HTTP) service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the [HTTP](HTTP) service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.  \nStatus of this Memo  \nThis Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.  \nInternet-Drafts are working documents of the Internet Engineering Task Force (IETF) . Note that other groups may also distribute working documents as Internet-Drafts . The list of  \ncurrent Internet-Drafts is at [http://datatracker.ietf.org/drafts/current/](http://datatracker.ietf.org/drafts/current/) .  \nInternet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use InternetDrafts as reference material or to cite them other than as “work in progress .”  \nThis Internet-Draft will expire on January 16, 2013.  \nCopyright Notice  \nCopyright (c) 2012 IETF Trust and the persons identified as the document authors . All rights reserved.  \nThis document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ([http://trustee.ietf.org/l](http://trustee.ietf.org/l)icense-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.  \nTable of Contents  \n1. Introduction  \n1.1. Roles  \n1.2. Protocol Flow  \n1.3. Authorization Grant  \n1.3.1. Authorization Code  \n1.3.2. Implicit  \n1.3.3. Resource Owner Password Credentials  \n1.3.4. Client Credentials  \n1.4. Access Token  \n1.5. Refresh Token  \n1.6. TLS Version  \n1.7. [HTTP](HTTP) Redirections  \n1.8. Interoperability  \n1.9. Notational Conventions  \n2. Client Registration  \n2.1. Client Types  \n2.2. Client Identifier  \n2.3. Client Authentication  \n2.3.1. Client Password  \n2.3.2. Other Authentication Methods  \n2.4. Unregistered Clients  \n3. Protocol Endpoints  \n3.1. Authorization Endpoint  \n3.1.1. Response Type  \n3.1.2. Redirection Endpoint  \n3.2. Token Endpoint  \n3.2.1. Client Authentication  \n3.3. Access Token Scope  \n4. Obtaining Authorization  \n4.1. Authorization Code Grant  \n4.1.1. Authorization Request  \n4.1.2. Authorization Response  \n4.1.3. Access Token Request  \n4.1.4. Access Token Response  \n4.2. Implicit Grant  \n4.2.1. Authorization Request  \n4.2.2. Access Token Response  \n4.3. Resource Owner Password Credentials Grant  \n4.3.1. Authorization Request and Response  \n4.3.2. Access Token Request  \n4.3.3. Access Token Response  \n4.4. Client Credentials Grant  \n4.4.1. Authorization Request and Response  \n4.4.2. Access Token Request  \n4.4.3. Access Token Response  \n4.5. Extension Grants  \n5. Issuing an Access Token  \n5.1. Successful Response  \n5.2. Error Response  \n6. Refreshing an Access Token  \n7. Accessing Protected Resources  \n7.1. Access Token Types  \n7.2. Error Response  \n8. Extensibility  \n8.1. Defining Access Token Types  \n8.2. Defining New Endpoint Parameters  \n8.3. Defining New Authorization Grant Types  \n8.4. Defining New Authorization Endpoint Response Types  \n8.5. Defining Additional Error Codes  \n9. Native Applications  \n10. Security Considerations  \n10.1. Client Authentication  \n10.2. Client Imperso","cbCainFjW9KCBgD8","https://ap.wps.com/l/cbCainFjW9KCBgD8","pdf",464456,49,"English","# Introduction\n## Roles\n## Protocol Flow\n## Authorization Grant\n# Client Registration\n## Client Types\n## Client Identifier\n## Client Authentication\n# Protocol Endpoints\n## Authorization Endpoint\n## Token Endpoint\n## Access Token Scope\n# Obtaining Authorization\n## Authorization Code Grant\n## Implicit Grant\n## Resource Owner Password Credentials Grant\n## Client Credentials Grant\n## Extension Grants\n# Issuing an Access Token\n# Refreshing an Access Token\n# Accessing Protected Resources\n## Access Token Types\n# Extensibility\n# Native Applications\n# Security Considerations\n## Client Authentication\n## Access Tokens\n## Refresh Tokens\n# IANA Considerations\n## Registries","[{\"question\":\"What problem does the OAuth 2.0 authorization framework solve?\",\"answer\":\"It enables third-party applications to obtain limited access to an HTTP service either on behalf of a resource owner via an approval interaction or on their own behalf.\"},{\"question\":\"How does this specification relate to OAuth 1.0?\",\"answer\":\"The OAuth 2.0 authorization framework replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.\"},{\"question\":\"What is the purpose and status of this Internet-Draft?\",\"answer\":\"It is submitted as an Internet-Draft in full conformance with BCP 78 and BCP 79, and it is intended as a Standards Track document.\"}]","OAuth 2.0 Authorization Framework - draft-ietf-oauth-v2-30 - Standards Track | PDF",1789839051]