REST API Authentication (part 2) - CourtneyR.dev's 2nd Brain

REST API Authentication (part 2) 🔗 **Source:** [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > [!note]+ Document Notes > tags: [WordPress, REST-API, Authentication] > author: [MISSING] > source: [YouTube] > reference: [https://www.youtube.com/watch?v=Ci73QXpIbWs] > date created: > > # 🏷️ Title: REST API Authentication (part 2) >  ## 🧰 Action Inbox - [H2] Publish CRUD-to-methods cheat sheet — video / https://www.youtube.com/watch?v=Ci73QXpIbWs&t=600 #articleseed - [H5] Ship Postman examples for posts endpoint — demo / https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1266 #xref - [H7] Write guide: application passwords for servers — demo / https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1687 #articleseed - [H9] Produce JWT + refresh cookie sample — demo / https://www.youtube.com/watch?v=Ci73QXpIbWs&t=2252 #articleseed - [H12] Document “store access tokens in memory” — demo / https://www.youtube.com/watch?v=Ci73QXpIbWs&t=3040 #addendum - [H14] Create OAuth2 + PKCE walkthrough for SPAs — demo / https://www.youtube.com/watch?v=Ci73QXpIbWs&t=3672 #articleseed - [H17] Publish scope-based permission matrix — demo / https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4111 #share - [H19] Add “custom endpoints auth” examples — demo / https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4837 #xref ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Video: “REST API Authentication (part 2).” https://www.youtube.com/watch?v=Ci73QXpIbWs - WP Application Passwords guide. https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/ - JWT overview. https://jwt.io/ - OAuth 2.0 and PKCE. https://www.rfc-editor.org/rfc/rfc6749 and https://www.rfc-editor.org/rfc/rfc7636 ## 📝 Summary - The session reviews WordPress REST authentication flows. It shows working demos. (https://www.youtube.com/watch?v=Ci73QXpIbWs) - It maps CRUD to HTTP methods and explains protected endpoints. (https://www.youtube.com/watch?v=Ci73QXpIbWs&t=522) - It covers cookies, application passwords, JWT with refresh cookies, and OAuth2 with PKCE. (https://www.youtube.com/watch?v=Ci73QXpIbWs&t=2252) - It recommends token-in-memory and secure, httpOnly refresh cookies. (https://www.youtube.com/watch?v=Ci73QXpIbWs&t=3040) - Bottom line: choose flows by client type, risk, and required scopes. (https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4111) ## 📖 Main Content - REST endpoints expose resources under `/wp-json/{namespace}/{version}/...`. Methods mirror CRUD. (https://www.youtube.com/watch?v=Ci73QXpIbWs&t=600) - GET often stays public. Mutations usually require authentication. Exceptions exist for sensitive reads. (https://www.youtube.com/watch?v=Ci73QXpIbWs&t=910) - Inside WordPress, cookies and nonces authenticate editor actions safely. (https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1266) - Server-to-server calls can use Application Passwords. Treat them like credentials. Rotate and scope by user role. (https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/) - SPA patterns prefer short-lived JWTs in memory plus secure refresh cookies. This reduces theft risk. (https://www.youtube.com/watch?v=Ci73QXpIbWs&t=2855) - OAuth2 with PKCE removes password handling from SPAs and adds granular scopes. (https://www.rfc-editor.org/rfc/rfc6749) - The same auth applies to custom endpoints. Capability checks must guard handlers. (https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4837) - Uncertainties: plugin implementations vary; host CORS and cookie policies differ by environment. ### 🗒️ Notes #### ⏱️ [00:04:50](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=290) Session framing ### [H1] Session reviews REST authentication patterns > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) by an unnamed author via [[YouTube]]. Published [MISSING]. Accessed . > “I'm going to start sharing an overview of the different authentication methods…” Sets scope and learning path. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=290) #articleseed ID:rw_[MISSING] #### ⏱️ [00:08:42](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=522) Methods and CRUD ### [H2] HTTP methods map to CRUD semantics > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “GET will correspond to read… POST to create… PUT to update… DELETE to delete.” Clarifies mental model for endpoints. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=600) #xref ID:rw_[MISSING] #### ⏱️ [00:16:42](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1002) WordPress REST overview ### [H3] WordPress restricts modifications by default > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “The WordPress REST API allows different actions, with modifications requiring authentication.” Explains default security stance. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1002) #xref ID:rw_[MISSING] #### ⏱️ [00:21:06](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1266) Editor save flow ### [H4] Block editor calls REST endpoints with cookies > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “Every time I save the block editor is performing the action by doing a request to the REST API.” Shows first-party cookie auth and nonces. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1266) #xref ID:rw_[MISSING] #### ⏱️ [00:28:07](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1687) Application passwords ### [H5] Application passwords support server-side automation > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “We can use application passwords… from a NodeJS application or CLI application.” Use for trusted servers; avoid in browsers. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1687) #articleseed ID:rw_[MISSING] #### ⏱️ [00:31:28](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1888) Basic vs app password ### [H6] Regular passwords should not authorize API calls > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “We really need to add application password.” Prevents dangerous credential reuse. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=1888) #xref ID:rw_[MISSING] #### ⏱️ [00:37:32](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=2252) JWT pattern ### [H7] JWT enables SPA auth with server-issued tokens > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “Ask the WordPress installation for a token that we can store somewhere.” Foundational SPA flow. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=2252) #articleseed ID:rw_[MISSING] #### ⏱️ [00:41:21](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=2481) Plugin endpoints ### [H8] Plugin exposes token, refresh, verify, and logout endpoints > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “This plugin… define a specific endpoints… generate the web token… authenticate the requests.” Details endpoint responsibilities. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=2481) #xref ID:rw_[MISSING] #### ⏱️ [00:47:35](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=2855) Secure cookies ### [H9] Use secure, same-site, HTTPS-only refresh cookies > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “Cookie… only be accepted on the same site… only work in HTTPS.” Hardens refresh flow. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=2855) #articleseed ID:rw_[MISSING] #### ⏱️ [00:50:40](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=3040) Token storage ### [H10] Store access tokens in memory, not localStorage > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “The token… will be stored in memory.” Reduces theft via XSS. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=3040) #addendum ID:rw_[MISSING] #### ⏱️ [00:57:32](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=3452) Server-side credentials ### [H11] Keep credentials away from client applications > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “Credentials are only entered on the server side.” Avoids password handling by SPAs. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=3452) #xref ID:rw_[MISSING] #### ⏱️ [01:01:12](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=3672) OAuth2 redirect ### [H12] OAuth2 with PKCE grants scoped permissions > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “We are authorizing the client-side application to do some things on our behalf.” Enables least-privilege flows. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=3672) #articleseed ID:rw_[MISSING] #### ⏱️ [01:08:31](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4111) Scopes ### [H13] Tokens encode scopes for read or write actions > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “Permission scopes determine the level of access granted to an application.” Promotes granular access. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4111) #share ID:rw_[MISSING] #### ⏱️ [01:11:54](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4314) Access and refresh ### [H14] Use access plus refresh tokens for sessions > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “We receive both an access token and a refresh token.” Improves UX and security together. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4314) #xref ID:rw_[MISSING] #### ⏱️ [01:20:37](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4837) Custom endpoints ### [H15] Same auth secures custom REST endpoints > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “Authentication methods apply to both core and custom endpoints.” Encourages consistent capability checks. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs&t=4837) #xref ID:rw_[MISSING] ## 📚 References - Video stream and transcript. https://www.youtube.com/watch?v=Ci73QXpIbWs - Application Passwords integration guide. https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/ - JWT background and tooling. https://jwt.io/ - OAuth 2.0 core and PKCE. https://www.rfc-editor.org/rfc/rfc6749 • https://www.rfc-editor.org/rfc/rfc7636 ## 🗣️ Paraphrase - The presenter compares several WordPress REST authentication patterns. - They demo cookies, application passwords, JWT, and OAuth2 with PKCE. ## 📰 Newsletter - **Auth patterns for WordPress REST, explained.** - Use cookies for editor actions. Prefer JWT-in-memory with refresh cookies for SPAs. - Consider OAuth2 + PKCE for granular scopes and safer logins. - Helpful links: [Video](https://www.youtube.com/watch?v=Ci73QXpIbWs), [App Passwords](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/), [JWT](https://jwt.io/), [OAuth2](https://www.rfc-editor.org/rfc/rfc6749). ## ✅ Action Items #### DevRel - Publish runnable examples for each auth flow. - Record a 7-minute SPAs + JWT refresher. - Provide Postman collections for core endpoints. - Add scope tables to docs and slides. - Run office hours on CORS and cookies. #### OSPO - Establish secrets rotation for app passwords. - Approve PKCE-only client registration for SPAs. - Mandate httpOnly, secure, sameSite refresh cookies. - Create incident checklist for token leakage. - Track auth method adoption in quarterly reports. #### Community - Host a “REST Auth 101” workshop at meetups. - Pair mentors with first-time API users. - Share sanitized code templates in a public repo. - Translate quickstarts for Spanish sessions. #### WordPress - Core: improve docs on nonce and cookie patterns. - Plugins: add capability checks to custom endpoints. - Documentation: add JWT + refresh reference patterns. - Training: build labs on scopes and roles. - Playground: include OAuth2 + PKCE example app. - Meta: publish guidance on CORS headers and cookies. - CLI: ship examples to test REST auth health. - Hosting: standardize reverse proxy headers for auth. - Support: produce troubleshooting flowcharts for REST auth. #### The WPOCC - Fund microgrants for security-focused plugin audits. - Sponsor bilingual tutorials on REST auth flows. ### FAIR - Publish provenance for demo tokens and diagrams. - Propose policy for scope-limited automation keys. ## 🧪 Hypotheses - JWT-in-memory lowers token theft incidents by 30% versus localStorage. - OAuth2 + PKCE reduces credential exposure risk by 50%. - App passwords increase server automation adoption by 20%. - Scoped tokens cut unintended writes by 25% in SPAs. ### 📊 Methodology - Compare security incidents before and after migrations. - Run A/B tests on SPA storage strategies. - Survey developer adoption across teams quarterly. - Analyze write error rates by auth method. ### ❓ Questions - Which hosts restrict httpOnly cookies for subdomains? - What scope taxonomy best fits common WordPress roles? - How should we expire refresh tokens safely? - Where should CI store application passwords? ### 🔮 Future Research - Explore DPoP or MTLS for higher assurance APIs. - Prototype WebAuthn-powered token issuance. - Standardize custom endpoint capability declarations. - Build lint rules for REST auth misuse. ### 💡 Implications - Clear patterns reduce auth bugs in production. - Scoped tokens encourage least privilege practices. - Better docs improve contributor onboarding. - Hosts can ship safer defaults at scale. ### 🧠 Learning Styles Assessment - Reading level estimate: **Flesch-Kincaid Grade ≈ 10.8**. #### 👀 Visual learners - Present: diagrams and network tabs. - Improve: end-to-end flowcharts and swimlanes. #### 🔊 Aural learners - Present: narrated walkthrough. - Improve: concise audio recap with glossary. #### 🗣️ Verbal learners - Present: definitions and examples. - Improve: compare flows with analogies. #### 🧩 Kinesthetic learners - Present: live Postman and React demos. - Improve: copy-paste labs and checklists. #### 🧠 Logical learners - Present: CRUD mapping and scopes. - Improve: decision trees for method choice. #### 🧑‍🤝‍🧑 Social learners - Present: Q&A prompts. - Improve: cohort challenges with reviews. #### 🧘‍♀️ Solitary learners - Present: repo of demos. - Improve: self-check quizzes per module. #### 🌿 Naturalistic learners - Present: none noted. - Improve: lifecycle diagrams for token rotation. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: headings and lists. - Improve: alt text for diagrams and code labels. #### Keyboard navigation - Present: CLI flows avoid traps. - Improve: tab order guidance in sample apps. #### Contrast and readability - Present: terminal output reads well. - Improve: ensure 4.5:1 in screenshots. #### Text resizing and reflow - Present: responsive notes. - Improve: prefers-reduced-motion in demos. #### Media and captions - Present: YouTube captions exist. - Improve: downloadable transcripts and chapters. #### Forms and interactions - Present: login forms in demos. - Improve: inline errors and accessible toasts. #### Standards reference - Map gaps to WCAG 2.2 AA criteria. ### 🌍 DEIB Assessment #### Cultural breadth - Present: bilingual commitment. - Improve: more non-English examples. #### Inclusive language - Present: mostly neutral terms. - Improve: define jargon inline. #### Neurodiversity support - Present: chunked structure. - Improve: icon+text labels consistently. #### Representation - Present: single presenter. - Improve: feature diverse guest devs. #### Psychological safety - Present: respectful tone. - Improve: publish contribution guidelines. ### ✅ Logical Validity #### Strong reasoning - CRUD-to-method mapping is standard and clear ([H2]). - Scoped permissions logically constrain actions ([H13]). - Memory storage reduces XSS exposure compared to localStorage ([H10]). #### Fallacies - Possible overgeneralization of cookie settings across hosts. - Fix: document host-specific caveats and alternatives. - Implicit security claims without metrics. - Fix: add incident data and benchmarks. #### Tone of voice - Instructional and pragmatic throughout. ### 🛡️ DARVO Analysis - Deny: none observed. - Attack: none observed. - Reverse victim/offender: none observed. - The rhetoric stays technical and neutral. ## 🎯 Conclusion - Choose auth flows based on client type, risk, and scopes. - Prefer JWT in memory with secure refresh cookies for SPAs. - Use OAuth2 + PKCE when you need granular, user-approved permissions. - Keep application passwords server-side and rotate regularly. ## 🏷️ Tag Coverage #articleseed: 5 • #xref: 5 • #share: 1 • #bmf: 0 • #addendum: 1 ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) by an unnamed author via [[YouTube]]. Published [MISSING]. Accessed . > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [REST API Authentication (part 2)](https://www.youtube.com/watch?v=Ci73QXpIbWs) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight](https://www.youtube.com/watch?v=Ci73QXpIbWs#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] JWT-in-memory reduces XSS token exposure - Scope: SPAs interacting with WordPress APIs. - Pointer: 00:50:40. - Links: [[Token-Storage]] [[SPA-Security]] #### [Z2] OAuth2 + PKCE enables least privilege for SPAs - Scope: third-party clients needing user consent. - Pointer: 01:01:12. - Links: [[OAuth2]] [[Scopes]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Draft JWT refresh cookie snippet — context/https://www.youtube.com/watch?v=Ci73QXpIbWs #fleeting #inbox - [F2] Build OAuth2 scope matrix — context/https://www.youtube.com/watch?v=Ci73QXpIbWs #fleeting #inbox - [F3] Write App Passwords rotation runbook — context/https://www.youtube.com/watch?v=Ci73QXpIbWs #fleeting #inbox ---  ## 📺 Video ![](https://www.youtube.com/watch?v=Ci73QXpIbWs) --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=Ci73QXpIbWs)* **[04:46]** and and we are in. Let me get some context about this session. So today's session. Yeah. I want to put this here. Yeah. **[05:20]** Okay. Hello. How are you? How you doing? Welcome to another stream. Um, as uh some of you know, I do regular streams every week. I usually do them on Fridays, but because tomorrow I'm traveling to a war camp, I'm doing it today because I don't want to to miss any week streaming. And also I'm going to use this stream as um review of the **[05:54]** topics that I'm going to demo in the work Githia this Saturday. I think the topic is like very very big. So there's a lot to talk about this and I would like to show some of the demos and some of the clear ideas that I want to share in the in the in the demo that I'll do at work Galithia. **[06:25]** So I'm going to start sharing an overview of the different authentication methods we have for the race API and then I will go one by one um showcasing how we can actually access the data that is protected. Um so yeah let's let's start with a diagram that I did in **[06:59]** the previous session that I'm very happy with it because well it's actually here in this in the is this diagram So yeah, these are the most popular ways to access data that is in the rest API **[07:31]** and data that is uh protected. So if because there is a lot of data that is not protected that is that is public but uh especially those um well going going a bit uh back the rest API let me open a diagram let's continue the diagram we started here **[08:03]** in the preview session that I did in by the way I'm going to share I'm going to share this in the in the chat because this is the link to the repository where I am compiling all the information from previous sessions. So for each session you have like a link to the video and a link to all the resources that I have used uh during the session. So for example for this session **[08:35]** I worked on this on this diagram which by the way the cookies of workflow is great but this one I have a better one so I'm going to remove it. Going to remove it. Okay this is lock so I'm going to lock it. Okay, so these are the authentication methods. **[09:06]** Um so the rest API has like data accessible via different endpoints and each endpoint can be accessed through different methods. And the methods that are usually that are uh usually um defined are uh **[09:39]** the get method get method. Usually with the get and post method we can do like most of the operations and we will usually deal with only this method. So for example, the same endpoint can have uh like the get uh version of that endpoint and the post version. But there are also some other methods like delete **[10:11]** um like delete uh put some others. Uh basically each one of these methods that we can use to access the the different endpoints, they correspond to a specific um C UD operation like a **[10:45]** if we go to [Music] which uh corresponds to the this are this is the acronym is the is the word. So this is a create and I'm going to create **[11:22]** Just create um [Music] what uh read update and delete. So each one of these methods corresponds. So for example, get will correspond to read usually **[12:00]** uh post to create delete to delete and put to update. This is in theory but then sometimes we can um we can find update operations being done using the the post uh **[12:30]** the post action but uh this is semantically this is what they are supposed to do. Okay. So yeah we will have like different endpoints and the endpoints in WordPress they follow this syntax. So all the endpoints are after DVP JSON then we have a name space then we have a version **[13:02]** and then we have the specific path and with all of that we get the endpoint. the endpoint is called the the mix of the method and the specific path. Okay. So having clarified a little bit the syntax for the for the different endpoints then we can **[13:34]** talk about authentication. So um I'm going to group this group selection. Okay. So usually usually this um usually this method the get method **[14:05]** doesn't require authentication but these other ones they usually require. Mhm. So this is going to be this and it's going to be this usually. So as um I'm going to add a note here that uh get end points **[14:36]** usually [Music] don't require [Music] and we can say here something like yeah something like this something like is um and this like post, delete and put endpoints usually **[15:08]** um require authentication. But there are also some specific uh get methods that also require authentication like for example um unless it's uh sensitive uh or private data. So yeah as a rule of thumb we can use we can say this like the get methods they **[15:39]** usually don't require authentication and post delete and put they most of um in most of situations they will require authentication but some get actions will require authentication. For example, if we are locked into a system to get the profile information of the locked user, we need to authenticate ourselves because we cannot access the data of any user. We can only access all data. So this is an example of a get **[16:10]** action that needs h authentication. Okay. So let's go to a WordPress installation and we can explore uh this a bit more. We talked about this in the last session. So I'm going to do like a a quick review and then I would like to show some some demos especially using these uh workflows. But I think it's nice to um review all the **[16:42]** authentication methods. So if I have here my WordPress instance uh run by WordPress studio, I can open the instance instance and I have it here and I have here the **[17:18]** let me see if I can access the network and if we go to post my post here hello from the API okay Here we can see a lot of um **[17:50]** a lot of requests. Let me filter this byp JSON. So in WordPress the rest API. [Music] >> Okay. What happened? I lost the I lost the Don. **[18:21]** [Music] Oh my god. Um I lost the changes that I have just Well, I can repeat that later. Um, yeah, I think I lost them. I think I lost them. **[18:57]** Okay, let's um Mhm. Okay, let's go back. Let's take this scaly **[19:28]** diagram again. Replace my content. Yes. And Let me open this again. Scalletro. Okay. Um let's uh start again. We'll repeat this diagram **[19:58]** later. Yeah. I unlock and I can. Okay. So, we had like these different uh methods and some of them we can uh authenticate. uh as some of the methods that are used for the endpoints like the the reading ones they usually don't require authentication but the the modifying **[20:30]** data ones are the ones that require authentication. So starting with uh cookies this is the method that is used internally by the block editor. So if we go to the block editor here, we can see that every action we do uh we move and we uh maybe add a paragraph here and say hello **[21:02]** again. And then we save the draft. And then um maybe we change the color here. We save the draft again. Uh then maybe we move this. So um which actions can I do? Well, I can I'm **[21:32]** saving the draft. I can I can maybe what these actions are I don't know there are more actions that can be triggered from the block editor but these ones are uh clear that every time I save the block editor is performing the action by doing a request to the rest API in this case to the posts **[22:04]** um endpoint. Actually, if we um if we check here, we can see that the this is the endpoint and it's a it's a post. **[22:35]** So I need to bust. Yeah. [Music] This is a post. And because it's a post um because it's a post we need to authenticate because we are creating a **[23:06]** new post with this uh request. And we can also see here the payload contains the information of the post we are creating. So this is a request that we can do. we can send a post request to this um to this and we can send this data. This is an example of a post method that is being used to update the content of a post. **[23:37]** And here's the the payload for the ID for the this is the ID of the post we are requesting to update the content to be this. And the response that we got is the new um state of the post after internally WordPress has um has updated the information of the post. Okay. **[24:18]** So how is this endpoint validated? So in the headers we can see response. No, in the request headers we can see that along with the request there are some um yeah some headers with the request and one one header corresponds to the cookies that are sent on each request. And here we have um a cookie. Here's the **[24:50]** cookie WordPress uh logged in. I think is this one. This is the cookie used by uh WordPress to verify that this uh action is performed by an author authorized user. Okay. >> Okay. **[25:25]** Um okay so the rest API endpoints internally are validated validated via cookies so we don't need to do anything once we are logged um >> we can perform Um we can perform actions using the the internal cookies. **[26:00]** Okay. Um, so the interesting thing about this is that if we develop something inside WordPress, we don't really need to worry too much about the authentication because there are uh tools that will manage that for us. So if we do a request to the rest API **[26:32]** from within the same domain, we will attach to each request the cookie and that cookie will be used to authenticate authenticate us. So we will be able to with the locked user if we are the admin or if we are any other user we we will be able to perform like different actions but also internally there is a um a thing that is sent that is called a **[27:03]** announce that is here this is an extra security measure. So the WordPress can check can verify that the request has been done from um from a specific source we attach. So if um **[27:34]** so if someone gets our cookie somehow it cannot um it cannot make like actions on all all behalf. That's the idea of the of the noises. So yeah this is a an extra security measure to to increase security in the this internal uh request. Okay. That's one way. Another way is application passwords. So **[28:07]** this is for requests done from within a WordPress site. You can see uh it goes through this process and then uh at the end it uh triggers the endpoint call back. But then we have um if we want to perform operations from the outside of a WordPress site, for example, from um from a NodeJS application or um yeah CLI **[28:37]** application, something like that. We can use application passwords that um for example let's imagine that um we want to perform this operation this same operation but from the outside we need to authenticate ourselves. Let me see if I can replicate this. Okay. So this is the **[29:28]** But so we can come here. This is the the URL we can do a get in theory we don't need authentication to do a get request to this uh to this endpoint but if we do a post okay because I have added well in this **[29:59]** case I am adding here an author an application password that is actually created but Uh let me go let me go to my user. I'm going to remove that application password. This is this is what I'm going to revoke. And now if we go to here, yeah, you are not allowed to edit this post because we **[30:30]** need some form of authentication. And this is where we can use application passwords. Application passwords. What we can do is go to our user or user profile. If we go to users and then we click in our user below there is a section called application password. And here we can say um [Music] **[31:02]** we can add a specific application password and this is the password we can use for the request. So we need to um attach to the request. We also need to send our user and this application password. We copy this and if we go to postman we can do this. We can um attach the username and the password and being the password application password **[31:34]** that we have created. So now we are authorized to do the the operation and the body that we can I think is a I think the body needs to be a content. Um, **[32:05]** okay. I'm going to simplify this content. Hello from [Music] And what else? Uh, I think that's all. We can update the content to be this. If we send a request and then we go to the post, **[32:37]** we can see that the content corresponds to the one that we have uh updated from from here. What happens if instead of using the application password, we use a real password? Let's check that. I'm not sure about that to be honest. I think in some systems it works but I think um here it doesn't. So we really need to add application password but we can check that **[33:09]** this is my uh password and if we say body uh hello from my real password action. Yeah, we are not allowed to edit the post because we need to use our application password that it was it was here. So, uh here in the body **[33:43]** hello from um using my application password. And here if we go to the WordPress installation, yeah, this is the content that we have updated. But as you can see, we have done this request from the outside of WordPress. We are not doing that uh from from within. **[34:16]** So coming back to our diagram which is this uh we have cookies, we have application passwords. Okay. And then uh we have other methods that are more secure because here with the application passwords what's happening is that we are providing all credentials on every request which is not like super secure. This is a valid approach if uh we are **[34:48]** using um if we are interacting with the WordPress instance from a server application from a server application um or for a CLI application in that case um because we have access I mean for local uh developments of course is a valid um option for server side, it may be a valid option. But for a client side **[35:20]** applications connecting to WordPress, this is not recommended at all because we are sending our credentials on each request and those credentials can be um can be seen by other actors. Um so this is not really a recommended approach if we are um creating client side applications interacting with uh WordPress. **[35:54]** There are other scenarios where this is not recommended because also application passwords are um are not limiting any any of the uh capabilities of the user. So with uh with those credentials the request um can be I can do anything that the user can do from the from the dashboard from **[36:26]** the admin dashboard and that can be dangerous um especially if we are if we are using the admin user or any other user with a lot of um capabilities. So that's another thing to take into account. Um also if someone um get gets access to this password, it can perform actions on your behalf until you revoke manually the the the password. So **[37:00]** that's another thing to take into account. So uh summarizing this is a very insecure way but it can be a valid solution if we are h in a secure environment uh or in an environment that we trust like for example we are creating a tool locally for our local use application passwords is a um valid solution and also if we have um solution **[37:31]** running on the server and we load those credentials via environment variables or so then I think that's another valid solutions but if we are dealing if we want to create um client side application like for example a web app or um yeah react application or something like that then we need to to look for more secure ways of providing access to to WordPress and **[38:06]** one way is to use a JSON web token. So what we can do is to ask for WordPress installation for a token that we can store somewhere and that token will um will represent the permission we are giving the app to act on our behalf. And that JSON web token will also contain information about ourselves and some other info. Um so that's a um pretty **[38:38]** popular solution for dealing with this uh type of authentications. So what we can do is showcase some demo uh about this and I have here some demos. Let me let me go to the terminal. Let me go to the terminal. **[39:25]** And if we go to projects. Okay. If we go to the this web token demo here we have a demo that we can we can use to check what is a um a **[39:57]** workflow that we can uh implement in our applications. And this is actually a pretty secure workflow, the one I'm going to show you, but it needs a specific plug-in on the WordPress side. And if we go to WordPress.org or plugins and we look for JSON web tokens. **[40:29]** There are a few of them but I have created a custom one that satisfies my needs in terms of security. And this is the one that I'm going to use. If we go to demos, **[41:00]** we can see a diagram. Okay. So this is the diagram of the React application. This is our WordPress um instance with this plug-in installed because this plug-in is the one that is going to define a specific endpoints. It's going **[41:33]** to generate the web token and it's also going to authenticate the the requests to check if the token that is to check if there is a token with the request and also if it's if it's a valid token but it also implements other secure ways of dealing with JSON web tokens in client applications that is providing a secure cookie with a refresh token. So we can **[42:05]** use that refresh token to whenever we refresh to get a new token. So what we can do to showcase all of this is to open the diagram here. I haven't changed here anything. Um, but I'm going to **[42:36]** I'm going to save to a sharable link. Copy link. I'm going to Okay, this is the the link of the diagram. Something that I should have done before because uh to avoid losing any data. And now I can I can open this data, **[43:06]** replace my content. And what I'm going to do is I'm going to have this on one side and on the other side I'm going to open this demo and So with this application we can this um approach I mean using dealing directly **[43:38]** with a server that provides JSON work tokens is a good approach if we want to rely completely on the user database of the WordPress instance. For example, if we want to create if we want to create a React application, but our users database, we want it to be the same one that is on WordPress. This is like a very typical headless WordPress application. We can use JSON web tokens. So in our application, we will have um a **[44:09]** login form. The users will enter their user and password and those users and passwords will be internally managed by WordPress. So here uh in our React application, let's also open the console console and the >> Okay. **[44:43]** the console. So I have here this application is already configured to to interact with this um this WordPress application and uh I have here a plug-in promp API which has some settings here **[45:16]** and it requires defining a secret key which I have uh already defined and then there is some settings like for example the token um XPV in seconds. I think this is uh yeah 1 hour and then also the refresh token. So we are going to receive whenever we are um properly logged in. We are going to get **[45:47]** two things. We are going to get a token but then we are also to get a refresh token but they will be delivered in different ways. The token will be delivered directly as the response of all request but the refresh token is going to be delivered uh via a secure cookie. So there are a lot of ways to implement this but I think this one is a pretty secure one and this is the one that I would recommend for for client **[46:19]** side applications because having the refresh token on a secure cookie um will prevent that any malicious code can access to the refresh token and that can get this JSON web token and the the token that we will use to validate the request we will store it directly in memory. So it's a pretty secure way to avoid um like malicious code accessing our **[46:50]** tokens or um like the way we are um we are saying to the app to act on our behalf. Okay. And then we have some other um settings for example to interact because when we interact with two different uh URLs we need to deal with course but but **[47:21]** here the this one is on 51 73 51 173. This allow origin. So the react application will be able to do requests to the to the server. And then there are some cookie settings that right now because is detecting that we **[47:51]** are in development is like um it's not super secure. But we can increment the security by restricting that the cookie can only be um accepted uh only on the same side. So in this case we would need to uh deploy the react application in the same uh URL than the uh WordPress application. then um **[48:23]** it only it can only work in HTTPS um connections. So in this case it works because we have an HTTPS connection here in the in the in the WordPress. And then um we can restrict specific paths, we can restrict to specific domains and we can uh we can restrict like um **[48:54]** like some other things. So um with this configuration in place we can start them and we can the credentials uh we are going to log in with the admin user. So admin and the password. So what happened here? **[49:26]** What happened was that from our react application we have done a request to this endpoint. Uh if we go to the to this WordPress site and if we go to WPJSON, [Music] we can see that with the with the plug-in installed, we have these endpoints **[49:58]** and we can see the different endpoints. So the token endpoint is the one that we use to get the the token that will allow the app to act on our behalf. Then the refresh token is the uh endpoint that we'll use to get a new token. refresh token using the refresh token that is available when it we will be sent a along with the **[50:31]** request because it will be in a cookie and then some other endpoints for example if to verify if the token is valid or to log out directly so this will revoke the the current token so it's uh JWBT v1 and token. If we go here, we can see in network that we have done a request. **[51:03]** We have done a post request where we have sent our username and our password and we have received a specific token. So we have done a request and we have received a JSON web token and this token will be stored in memory. But also if we come here to application cookies we can see that we have also received a **[51:33]** refresh token. Why is that? And also that D refresh token is um is secure. It can only be accessed uh via HTTPS and and a lot of uh things. It's more secure than than the others. So we have this refresh token. And the cool thing about this is that let's go **[52:04]** to network. Let's close this. If I reload the page, I will do um automatically um request to the refresh endpoint. In the request header, I'm attaching the specific refresh token and I'm going to get a completely new JSON web token. **[52:36]** This one ends in NH and the other one ends in in a different thing. And every time we refresh, we can get a a new token. So this is a cool way to manage authentication via JSON web tokens because the token is stored in memory and is not stored in local storage or uh session storage **[53:08]** which can provoke some security issues. And we also provide a way so whenever the um user refresh the page we can remain locked. So the user has to manually log out and then with whenever we do the log out the the token is uh revoked and the refresh token I think the cookie is removed. Let me **[53:39]** see. Yeah and the cookie is removed. If we go to network with the log out, I guess that one of the headers will be um one of the response headers will be yeah to remove the the token with the refresh token. Okay. So let's now use this **[54:17]** Let's do let's log in again. Admin password. This is the JSON web token. And what we can do now is try to access **[54:49]** the try to do a specific action using this uh token. Okay. So um let's check um okay I have here a specific in the demos I think I have here some examples of how **[55:21]** to okay here rest of demo we need to add uh an authorization better. So if we go here um I'm going to remove here and I'm going to change the authorization type from basic off that will be the uh **[55:51]** application password to better and the better is the the token [Music] that we got After we successfully logged in using our credentials and what we can do is hello from using my uh JSON web token and this is the preview and if we go to **[56:26]** our WordPress site made API post we can see that we have successfully change the content using our um JSON web tokens. Okay, so that's um one way of authentication authenticating endpoints. We are successfully authenticated um like restricted **[56:58]** actions. But then there is another um there is a a con of this uh there are pros and cons and one disadvantage of this approach is that the third like the the client side application needs to deal with the the credentials of the user. So we need to enter our password to the 30 to the uh **[57:28]** client side application and that's not the most trustworthy way of uh dealing with the credentials of the users. So there is another approach which is more secure is more complex but it's more secure that is um a workflow where the credentials never touch the client side uh application. The credentials are only entered into **[58:00]** the the server side um place the server side application that is actually managing the the the users. For example, you have seen this in in a lot of times like for example when we want to provide access to our GitHub um account or to our **[58:30]** Google uh services sometimes from 30 H third third party app applications we get redirected to Google. So we get logged in and also we are asked about the specific permissions that we want to give to this application. So once we um have given permissions to to the app then we go back to the app and the app gets a token to act on our behalf with a specific **[59:02]** scope of the permissions that we can do. and okay. So, let me going to run another application. So, **[59:35]** I'm going to start this one. Clear and I'm going to run npm. And here I have another application is this one. **[60:09]** And in order to use this application, I need another plug-in installed on the WordPress site. So, if I go to the WordPress site, I can go to plugins, deactivate this one. I'm going to activate this one. Okay. So this plug-in if we go to **[60:42]** settings it will allow like client side applications to connect with this WordPress instance and to get access to a specific actions and the third party app will never touch the credentials of the user. So what's the workflow exactly? Uh let me see if I can find the the diagram. I think I have it in in **[61:15]** cursor. So what I can do is going to the terminal that is uh where is the eyes here in the terminal. And what I can do is to um okay I am this is the repository with the demos. **[61:51]** This is the rhymi and this is the diagram. And this is the diagram. And no, this is not the is this one. **[62:33]** Okay. So this is the workflow we are going to to do. Our react application is going to request permissions to the WordPress uh server. We can ask for different permissions, but I'm going to be very restrictive. So, for example, I'm just going to ask for one permission. And whenever I request the permission, **[63:05]** I'm going to be sent directly to the WordPress um server. And also what I'm going to do is I'm going to to log out here because if I am not logged in, the WordPress site is going to ask for my credentials. So I'm going to copy the password and let's see what happens. I request the **[63:36]** permission and I've been sent to the to WordPress. This is my my local URL of my uh WordPress installation and also let me store this is my password. These are my credentials. **[64:08]** Um URL parser we can see this URL like the query string. So whenever I'm successfully logged in, I'm going to be redirected to another URL um which is the screen where I will **[64:40]** authorize the the specific permissions I want to provide the the app to act on my behalf. So first I'm going to log in And now I have been redirected to this other URL. If we check that URL, **[65:12]** we can see that part of the parameters that are being sent are the the client ID. And this is something that I need to this is something that if we go to now I'm logged properly. If we go to dashboard to the settings, we have the client ID **[65:48]** ah demo client that is the one that is being registered that is registered demo client and then we have like some extra security measures like a a pay pkce which is like a an extra code to to ensure that the request um is done from a secure place. **[66:19]** So here we are in the WordPress uh installation. We are still here. Uh we have um successfully logged in and now we are in the authorization page. We are from the WordPress site. We are authorizing the client side application to do some things on our behalf and those things are explained here. So the user can allow or can cancel. So this is like in terms of security this is a a **[66:51]** really good experience for the user because the user um like has to specifically has to provide access to specific actions. So here I'm allowing to to do this action view my posts pages and profile information and now I have been provided with this permission grant the permissions. Um **[67:23]** what else? If we go to the console, if we go to the console, um, okay, let me do this process again. I'm going to remove this because I'm already logged in. I'm not going to be asked to login again. But if I do this, **[67:56]** then the process is the same than with the uh direct JSON web token. I'm getting the the token here as as the response, but also I'm getting a cookie that I can use to get a new token every time I refresh the application. So, this is like a pretty secure way to manage uh tokens because **[68:29]** tokens are stored in memory. they are not stored in local storage and then we can use like this way to to get a new tokens. Okay. So now that token represents a specific permissions for the that I have given to the app to act on my behalf. So this is really interesting because even when I have logged in as an **[69:00]** administrator and as an administrator I have all sorts of um permissions in the in the app. Here I have permissions only for um for some things. In this case, I have only provided access to to read only permissions to read things. And in this demo, for example, we can check that we can read posts, we can read the **[69:34]** user profile, we can read comments, but we cannot create a post. You can see here that we cannot create a post because the scope is insufficient. But if we uh log out here and then we ask for write permissions here I'm asked to specify that I want to uh give uh these **[70:07]** permissions. Then I have more permissions. I have read and write permissions and I can read the user profile. And I can also create a post here. And if we review the the diagram, we can see that the red application whenever we want to um **[70:41]** get permissions to do something on the WordPress site, we are redirected to the WordPress site. We're redirected to O authorize sending uh like the client ID the redirect URL the code challenge in the client side we are um we log in then we go to authorization page to provide permissions and then we **[71:12]** are returned with an authorization code with an authorization code. That is the one that we use to this is the code that we get **[71:42]** and with that authorization code we uh ask for the token and then we get uh we get the token and also we get a refresh token in the cookie. So now we can do the the API request like for example this and then uh whenever I refresh uh the page or if the token has been expired we can use the refresh token to get a new access token. **[72:15]** So this is more or less the workflow. But this um authorization methods they work not only for core endpoints but also for custom endpoints. So let's let's check that. If we go to WordPress **[73:09]** Okay, if we go let me see here in install plugins. Yeah, I have here this endpoints. This is um plugin with extra endpoints. If we go to WBP JSON, **[73:39]** it's WP JSON. We can see that we have uh this name space and this version. So if we go to we can see that we have this extra endpoints register and some of them are uh protected. So what we can do is use this uh **[74:10]** authorization methods to also check if we can access this specific uh endpoint. So for example, public stats is something is something that shouldn't require any. [Music] What we can do is go to **[74:47]** Um, okay. I'm not going to add any authorization. No off. Yeah. So, these are the the stats for the site and we don't require any uh authentication method. Then we have user data protected user data. And we cannot access this user data **[75:17]** because we need to authenticate ourselves. And we can do that with the basic of or we can also do that using the the token. So if we check the last time this token should work. Let's check **[75:48]** that. So this is the better token. No, this token is okay. So we can also use or we can use also the um the JSON web token. Okay. **[76:19]** What else we can do here? H editor only my drafts. Yeah, these are protected but we should be able to access uh this drops. And also profile protected profile. **[76:56]** Protected profile. Okay. Because this is a post uh method. and this post method. Let's check this is the profile. That is a put. **[77:27]** And what we can do is to uh to use this. So yeah, this is a put. We need to add this and the authorization should be this one. If we select no off, we don't have **[77:58]** access. But if we use the token uh we should have access and our profile has been properly updated with uh this information. So let's check that we can properly and if we go to users **[78:37]** and we can see that we have updated this. We can maybe Okay. So we can see that all these authentication methods they work not only for core endpoints but also for custom endpoints and the custom endpoints they are registered. **[79:17]** Okay, let's check also the get uh posts and none. Okay, because there are none published. But if I go to posts and uh this is a draft a **[79:51]** draft and I'm going to publish this one and also publish this one. If I go to Postman now, we can see this one. And we should have here some new values **[80:26]** that is a register field for post. we have register uh reading time author vo and view count author vo and view count. So we have these three values that we have added to the post uh to the post field. And then we have registered post meta that it should be here in metadata something. **[81:04]** Okay, let me see where is this um view count. Mhm. update uh view count. **[81:35]** Okay. So this is a metadata that is uh registered but is displayed here. Okay. And then we have like the different callbacks for the endpoints. So these are the custom endpoints that we are registering. For example, this one doesn't require any specific uh permission, but this one **[82:06]** requires for the user to be uh logged in. So if we access protected user data uh without providing any authentication method, then we won't get anything. Then we need a specific user with H editor permissions. And then I again we need to provide some authentication uh **[82:37]** data to to get access to to this. Okay. Nice. So going back to our original diagram which was here. We have seen how do we have this authentication methods. Um we have **[83:09]** cookies that are uh used internally by the block editor. Then we have application passwords that can be that can be created here under users admin. We can create an application password. We can revoke them. The thing is that with every request we do, we need to **[83:43]** we need to [Music] we need to provide those credentials and that's uh can be insecure only acceptable If um [Music] **[84:34]** H. So with the application password what we do is we send the the credentials on every on every on every request as we can see here like um it was here. So that's not super super secure. **[85:08]** And then we go to some other authentication methods that are JSON web tokens and OO2. OF2 is like just a a series of recommendations um used to generate like secure workflows in order to authenticate users in in in applications. So the approach for JSON web tokens is **[85:42]** okay this is the demo this is the is this we have our react application. We enter our cred our credential from the client side application and we send those credentials to the WordPress site uh to a specific uh endpoint. Then we get the token. A secure way to store **[86:12]** the token is in memory. So um to avoid having to login every time we refresh the page, we can also incorporate to the workflow um a secure cookie with the information of a sec like a refresh token that we can use to get a new token every time we refresh. And this is like a good way uh a secure way to to manage this. **[86:44]** We can also use O off which is a bit more complex but also is more secure and it allows you to provide more granular permissions to um what your application can do on behalf of the user. So the way it works is that from our **[87:14]** application what we do is instead of entering our credentials from the client side from our our application we send the user to the to the entity that is managing the the users in our case the the WordPress application. So if the user is not logged, the user can loged in in the in the WordPress side and then in the WordPress site we are also asked for the specific permissions we want to provide the application uh to do on our behalf **[87:47]** and that's a um very nice screen where is very specific about the permissions we are providing and we can set a scope. So even if when our user can do a lot of things, we can limit the the things uh we are giving access the the application to do on our behalf and that's the scope we can give and we are uh the user will give explicitly the **[88:19]** permissions for the application. There are also some extra security measures like a PKC challenge that is used internally to verify that the that the request is being done from uh from a secure place. This is very similar to the nonsis that are used with the cookies uh from within WordPress. So we are redirected to the user login page then to the authorization page and then we **[88:51]** are h we get an oath code that we can exchange um for a token. So we send the authorization code and then we get the token with a refresh token in the cookie and that refresh token is the one we can use to refresh the page and get a new token every time. So the token is stored in memory. So no malicious code can access **[89:21]** our token and every time we need to refresh we get we send the the cookie and the cookie we can uh configure it to be as secure as we want. So we can restrict the specific domains, we can restrict HTTPS and a lot of things. And as we can see this works for any type of endpoints uh both uh cover endpoints and um custom endpoints. **[89:54]** Nice. So yeah, I think that this has been um nice way to wrap up this topic. I think that we have covered a lot. I will um leave the links of all the resources including the demos and the plugins that I have uh um developed and that um are aligned with the the **[90:26]** secure way to manage authentication from a client side application. Um, and yeah, let me know if uh what do you think about this topic and next week we will do another stream. So, let me know if there are some topics uh you would like me to to cover. So, I'm going to leave it here. Hope you have all a great weekend weekend. I am **[90:59]** going to work GIA work GIA and I'm going to um do a demo about this topic. So that's why I am uh so updated on these things because I've been preparing a a demo. If we go to to the program **[91:31]** in Spanish because this is in in gian where is the program Spanish here. Yeah. This is the demo I'm going to do that is exactly the same topic that we have covered today in a session. So yeah, hope you like it and also the the session is available here for you to check it later and **[92:06]** and also in this repository I am compiling all the sessions that I'm doing on a weekly basis along with all the resources that we are um that we use during the sessions. Um, I am switching languages. So, one week I do the stream in Spanish and the other one in English. And yeah, hope this is helpful for you. Hope this is useful for you. And and yeah, we're here in **[92:37]** discussions. I have this uh ideas discussion open. So, feel free to suggest new ideas. As I said, hope you have a great weekend and see you next week. See you.